ISO 27001 without certification: the ISMS as the backbone of the IT department
When we mention ISO/IEC 27001, the first association is almost always cybersecurity.
Risk analysis, security policies, access control, incident management, audits, compliance…
It makes perfect sense: ISO/IEC 27001 is the reference standard for Information Security Management Systems (ISMS).
But for an IT department, there is another way to look at this standard.
What if the ISMS became the backbone of information system management?
Not to turn the entire IT department into a gigantic ISO 27001 project.
Nor to claim that ISO 27001 meets all the needs of an IT manager.
But to have a common framework that connects business challenges, IT assets, dependencies, suppliers, risks, responsibilities, controls, incidents, and improvement decisions.
And this without necessarily seeking to obtain ISO/IEC 27001 certification.
ISO 27001 is primarily a management system
ISO/IEC 27001 is not just a list of technical cybersecurity measures.
It requires the organisation to establish a true management system that notably allows to:
understand its context and challenges;
identify stakeholders and their expectations ;
define a scope ;
identify and assess risks ;
determine responsibilities ;
define objectives ;
implement appropriate measures ;
monitor their effectiveness ;
manage incidents and deviations ;
measure results ;
audit the system ;
conduct management reviews ;
continuously improve the system.
Viewed from this angle, a question arises :
how many of these topics concern exclusively cybersecurity ?
Very few.
They are, for the most part, at the heart of an IT department's business.
This is what makes the approach particularly interesting.
The problem : the governance of the information system is often fragmented.
In many organisations, the management of the information system has been built up gradually.
One finds then :
an application mapping somewhere ;
an inventory of equipment elsewhere ;
supplier contracts in another tool ;
a project dashboard ;
a backup procedure ;
some business continuity documents ;
incident tickets ;
a security policy ;
a risk register ;
indicators for management ;
procedures for onboarding and offboarding employees ;
GDPR documents ;
audits carried out occasionally ;
and a lot of knowledge that remains in the heads of a few people.
Each element can be relevant.
The problem comes from the absence of a system linking everything.
The IT department then has tools, procedures, and documents, but not necessarily a true management system.
This is precisely where the ISMS approach becomes interesting.
Starting from business issues and risks rather than technology
An IT department can easily think in terms of solutions :
We need to replace the firewall.
We need to migrate the servers.
We need to deploy MFA.
We need to change the ERP.
We need to improve backups.
An approach inspired by ISO 27001 reverses the reasoning.
It starts by asking :
What are the essential processes and services for the business ?
Then :
What do they depend on ?
And finally :
What events could prevent the business from achieving its objectives ?
Let's take a critical business process : order taking.
Its operation may depend on :
Business process → ERP → database → infrastructure/cloud → network → identity → employees → service providers
From there, the IT department can identify the associated risks :
unavailability of the ERP ;
compromise of an administrator account ;
data corruption ;
cloud provider failure ;
human error ;
absence of a key person ;
excessive dependence on a provider ;
unusable backup ;
uncontrolled modification ;
insufficient capacity ;
cyberattack.
Cybersecurity naturally appears in this analysis.
But it only represents part of it.
We are no longer just looking to secure the IS. We are looking to manage the risks that the IS poses to the company's activities.
The ISMS as a backbone, not as a standalone system
This is where a distinction is essential.
ISO 27001 is not a complete management framework for an IS department.
The standard will not tell the IS manager :
how to arbitrate between 30 projects ;
how to build their IT budget ;
whether to replace their ERP ;
how to define their target architecture ;
how to optimise their SaaS licenses ;
how to organise their user support ;
how to accurately measure the total cost of an application ;
how to build an innovation strategy ;
how to manage their project portfolio.
Other methods, frameworks and practices are more suited to these topics.
On the other hand, the ISMS can provide the common structure that allows them to be linked to the company's challenges and risks.
This governance could be represented as follows :
GOVERNANCE OF THE IS DEPARTMENT
↓
ISMS / ISO 27001
Risks – responsibilities – controls – measurement – continuous improvement
↓
IT Services | Projects | Architecture | Suppliers | IT Finance | Continuity | Cybersecurity | Transformation
The ISMS is therefore not the entire building.
It can constitute the framework.
How far can the ISMS actually structure an IT department?
Using the ISMS as a backbone does not mean that ISO 27001 provides a complete answer to all the functions of an IT department.
Some areas are directly at the heart of the management system. Others benefit greatly from its governance and risk management logic. Finally, some disciplines remain largely outside its scope and must be supplemented by other practices.
| Area of the IT department | Contribution of the ISMS | What it concretely brings | What needs to be supplemented |
|---|---|---|---|
| Cybersecurity | Very strong | Risk identification, security measures, controls, responsibilities, monitoring and improvement | Tools, technical expertise and operational processes adapted to the context |
| Governance by risks | Very strong | Identification, assessment, treatment, acceptance and review of risks | Putting into perspective with all the risks and objectives of the company |
| Responsibilities and traceability | Very strong | Responsibilities, controls, evidence, audits, decisions and corrective actions | Operational organisation specific to each company |
| Dialogue with management | Very strong | Presentation of the IS from the perspective of risks, impacts, priorities, decisions and trade-offs | IS strategy, business cases and value creation |
| Continuity and resilience | Strong | Identification of continuity needs, dependencies, scenarios, measures and tests | Detailed BIA, PCA/PRA and crisis organisation adapted to the business |
| Supplier management | Strong | Identification of critical suppliers, associated risks, security requirements, monitoring | Purchasing, negotiation, economic management of contracts, sourcing and supplier strategy |
| Asset management | Strong | Identification of important assets, responsibilities, classification and protection | CMDB, asset management, licenses, technical life cycle and asset optimisation |
| Change management | Partial to strong | Identification and control of risks introduced by changes | Operational change management process, deployment, testing and release management |
| Incident management | Partial to strong | Detection, response, root cause analysis, corrective actions and improvement | Service desk, SLA, daily ticket management and ITSM processes |
| Operational IT management | Partial | Control framework, responsibilities, monitoring and control of certain operational risks | Service catalogue, SLA, user requests, support, capacity, availability and ITSM practices |
| Portfolio and projects | Low / indirect | Taking into account risks and security requirements in projects | Prioritisation, resource allocation, portfolio governance, project methods and value measurement |
| IT Architecture | Low / indirect | Security requirements and risk management in architectural choices | Enterprise architecture, urbanisation, target architecture, technical standards and IT trajectory |
| IT Finance | Low / indirect | Can help justify certain investments by the risks they mitigate | Budget, TCO, ROI, CAPEX/OPEX, FinOps, SaaS optimisation and IT management control |
| Innovation and transformation | Low / indirect | Enables the assessment and management of risks introduced by new technologies | Opportunity detection, innovation, experimentation, business transformation and value creation |
This table highlights an essential distinction.
The ISMS is particularly powerful in answering the question:
"How do we know what is important, what risks we carry, who is responsible and whether our control measures are working?"
It is much less suited to answer:
"What should our target architecture be? Which ERP should we choose? Which projects should we prioritise? What should our IT budget be? What technology could transform our business?"
That is why it would be excessive to say:
"ISO 27001 allows for the management of an IT department."
On the other hand, it is much more relevant to say:
« An ISMS inspired by ISO 27001 can provide the governance backbone on which the IT department can attach its other management disciplines. »
The distinction is important.
It prevents ISO 27001 from becoming a universal framework while leveraging what it brings that is particularly powerful: a structured method for linking business issues, assets, dependencies, risks, responsibilities, controls, evidence, decisions, and continuous improvement.
Linking the objects of the IS
This is probably one of the most important benefits of this approach.
Let’s take a server.
In a classic inventory, we can know:
its name, its IP address, its operating system, its version, and its location.
This is useful.
But to manage the IS, we also want to know:
What service does it provide?
What business process depends on this service?
What would be the consequence of its unavailability?
Is there a dependency on a supplier?
Who is responsible for it?
What risks are associated with it?
What measures can reduce these risks?
How do we know that these measures are working?
We gradually obtain a chain:
Business process
↓
IS services
↓
Assets
↓
Dependencies / suppliers
↓
Risks
↓
Control measures
↓
Responsible parties
↓
Indicators and evidence
↓
Incidents / deviations
↓
Improvement actions
This chain represents a much more interesting view of the IS than a simple juxtaposition of inventories.
A common language between the IT department and management
This approach also transforms the relationship with senior management.
A COMEX finds it hard to understand a discussion solely about:
firewall versions;
network architecture;
EDR;
patch management;
backup technology.
On the other hand, it fully understands:
"Our billing process currently depends on a component that constitutes a single point of failure. A prolonged outage would prevent billing for several days."
Or:
"We have identified four IS risks that currently exceed the level we consider acceptable. Here are the possible investments to reduce them."
The conversation changes.
The IT department no longer just asks:
"Can I get €50,000 to replace this infrastructure?"
It explains:
"Here is the risk we are currently carrying. Here is its potential impact. Here is what its reduction would cost. What decision do we wish to make?"
Management can then truly arbitrate.
And above all, it can sometimes decide to accept a risk.
Because good governance of the IS is not about eliminating all risks.
It is about knowing them and consciously making the appropriate decisions.
Supplier management
Let’s take another example: the suppliers.
An IT department must know its critical suppliers, the services they provide, their commitments, their dependencies, and the consequences of a failure.
The supplier can then be integrated into a chain:
Supplier → Provided service → Concerned assets → Dependent business processes → Risks → Controls → Monitoring
A contract renewal is no longer just an administrative operation.
It becomes an opportunity to ask:
Is this supplier still critical?
Is there excessive dependency?
Do we have an exit strategy?
Are their commitments appropriate to the criticality of the service?
Change management
A significant change in the IT system can cause:
unavailability;
functional regression;
data loss;
a vulnerability;
a performance issue.
Change management thus also becomes a risk control mechanism.
The question is no longer just:
"Has the change been implemented?"
but:
"Have we properly managed the risks introduced by this change?"
Business continuity and IT recovery
The business continuity plan also ceases to be an isolated document that is pulled out once a year.
It directly results from the analysis:
Critical process → dependencies → interruption scenario → impact → recovery objective → continuity measures → tests
This particularly helps to avoid a common pitfall:
investing heavily to protect low-criticality systems and insufficiently on those the business actually depends on.
Incidents become a source of improvement
In a poorly structured organisation:
Incident → repair → ticket closure.
In a management system:
Incident → cause → related risk → failed control → corrective action → effectiveness verification.
This difference is fundamental.
The incident is no longer just something that needs to be resolved.
It becomes information that allows for system improvement.
But not everything is a risk
This is also one of the limits that must be accepted.
Let’s take a CRM whose ergonomics cause salespeople to lose several minutes a day.
One can always transform the problem into:
"risk of productivity loss related to the ergonomics of the CRM".
But this becomes artificial.
The IT department must also know how to manage:
service performance;
user satisfaction;
opportunities;
innovation;
digital transformation;
technical debt;
projects;
costs.
A governance exclusively focused on risks could produce an excellent IT department to protect the company, but insufficiently oriented towards its transformation.
The ISMS must therefore remain a backbone.
Not a grid in which we try to artificially fit every IT decision.
Beware of the documentation factory
This is probably the main danger of the approach.
Implementing an ISMS should not consist of producing dozens of procedures simply to demonstrate that they exist.
The good rule could be:
Document only what helps to decide, execute, control or prove.
A risk register must serve to decide.
A mapping must allow understanding of dependencies.
An indicator must allow detecting a drift.
A procedure must allow correctly reproducing an operation.
A proof must demonstrate that a control actually works.
And when possible:
automate the proof rather than document the activity.
If the IAM tool automatically demonstrates that 100% of the relevant accounts have MFA and keeps the history of controls, producing a Word document solely to 'do ISO' adds little value.
The objective is certainly not to build an ISMS alongside the IT department.
The normal operation of the IT department must gradually naturally feed the management system.
And without certification?
This is another important point.
Using ISO/IEC 27001 does not necessarily mean wanting to be certified ISO/IEC 27001.
Certification can be particularly relevant when it meets a need:
client requirement;
response to tenders;
regulated environment;
need to demonstrate one's level of mastery;
international development;
competitive advantage.
But a small or medium-sized enterprise can perfectly decide:
"We will use the principles of ISO 27001 to structure our IT governance, without currently seeking to obtain the certificate."
This allows for adapting the level of formality to the reality of the business.
No certification does not mean no audit.
However, there is a risk.
When an organisation builds its own system, evaluates it itself, and concludes that it works correctly, it may develop an overly optimistic view of its maturity.
The absence of certification should therefore not mean:
absence of external oversight.
A periodic independent audit can be extremely useful, even without any certification objective.
Its role is not to obtain a certificate.
It is to challenge the system:
Are the risks really identified?
Do the controls work?
Is there evidence?
Are the responsibilities really assumed?
Are the action plans progressing?
Does the system really improve the control of the IS?
This way, we retain a large part of the value of the audit while remaining free from the level of formality sought.
A pragmatic model for a SME or a mid-sized company
The first level can ultimately remain relatively simple.
1. Understand the business
What are its objectives, constraints, obligations, and priorities?
2. Identify critical processes
What absolutely must work?
3. Map services, assets, and IS dependencies
What do these processes depend on?
4. Identify and assess risks
What could happen and what would the consequences be?
5. Define control measures
What are we doing to reduce these risks?
6. Assign responsibilities
Who decides? Who executes? Who controls?
7. Measure
How do we know that the measures are actually working?
8. Manage incidents and deviations
What have we learned?
9. Maintain an improvement plan
What do we need to correct, strengthen, or transform?
10. Organise a regular review with management
What risks remain acceptable? Which ones require a decision or investment?
Then around this backbone, the necessary measures for the business can be added:
service management, project portfolio, architecture, supplier management, financial steering, innovation and transformation.
From the technical IT department to the governance of the information system
Ultimately, this is where the main interest of this approach lies.
The objective is no longer just:
"How do we secure our information system?"
The question becomes:
"How do we control our information system so that it sustainably contributes to the company's objectives?"
Security is an essential component.
But it coexists with continuity, suppliers, skills, access, changes, obsolescence, technological dependencies, costs, service quality and transformation capabilities.
ISO/IEC 27001 does not provide all the answers to these questions.
And it is not intended to do so.
However, it brings something particularly valuable: a structured logic based on stakes, risks, responsibilities, measurement and continuous improvement.
That is why an ISMS can become the backbone of a management system for an IT department, without claiming to be the entirety.
Certification can come later if it presents a commercial, regulatory or strategic interest.
But it is not necessary to start.
The real objective is not to have a certificate on the wall.
It is to have an information system where dependencies are understood, risks are known, decisions are taken, responsibilities are established, and continuous improvement is organised — all while maintaining the capacity to innovate and transform the business.