Many people think that with ISO 27001, „we’ll just introduce a few policies and we’ll be ready for certification”, only to find out in the first few weeks that, in fact, day-to-day operations begin to change. In this section, we won’t be focusing on definitions, but rather on the changes that crop up most quickly in practice: where there will be more coordination, what needs to be clarified at short notice, and why documentation keeps coming up time and time again. The aim is simple: to know in advance what to expect and how to turn these „unpleasant” changes to your company’s advantage. (The same logic is at work throughout: risk-based decisions + verifiable, repeatable operations.)
Let’s start at the beginning
The essence of the ISO/IEC 27001:2022 standard is that you do not make decisions „on a hunch”: you prioritise on a risk-based basis, then consistently implement and periodically review what you have committed to. Documentation here is not a task to be ticked off a list, but a tool: the documented information and records (evidence) demonstrate that the company operates in a repeatable, controlled and secure manner.
Three changes in the first few weeks
1) Scope and responsibilities (not just IT)
What changes? One of the very first tangible outcomes is the documented scope of the ISMS: you set out which sites, systems, processes and information the system (and, later, the audit) covers, and why. At the same time, the role of management and information security responsibilities are defined: who is responsible for what, who makes decisions, who approves, and who takes responsibility.
The „downside”: It soon becomes clear that some things have, until now, „belonged to everyone” and therefore, in reality, belong to no one (e.g. approving access, managing suppliers, communicating incidents, etc.).
The positive outcome: A clearer decision-making process, fewer misunderstandings and a quicker response. Especially when there’s a problem, or when someone is off work due to holiday or illness.
Here is a specific example of what this looks like in practice and how it can be useful:
- Decision: the CRM system owner (e.g. Head of Sales) decides what role the new recruit should be given (e.g. „Sales rep” vs. „Team lead”), as they know what the job requires and what constitutes an excessively “broad” scope of authorisation.
- Approval: the system owner approves access; if there is an exception (e.g. admin rights), the ISMS / information security officer may act as an additional approver (as this is a risk-based decision).
- Implementation: IT / Service Desk sets the permissions in accordance with the requested role and records in a ticket who approved what and when (the assignment of roles, responsibilities and permissions forms part of the 27001 framework).
And what’s the point of that? IT doesn’t have to guess (faster onboarding), there is less chance of granting overly broad access rights (reducing the risk of misuse), when an employee leaves, the same audit trail works in reverse (faster offboarding), and in the event of a dispute or audit, it is possible to trace who made the decision, who configured the settings, and on what basis.
The result: less risk, more evidence, a faster decision-making process and fewer legal disputes arising from misunderstandings.
2) Risk management + SoA (at last we’ll have something to fall back on)
What’s changing? You’ll be required to have a risk assessment methodology (how you measure, on what scale, and how often), and you’ll also need to document the results. Part of risk management involves selecting controls, drawing up the Statement of Applicability (SoA), and putting together the risk management plan (what you’ll do, by when, and who’s responsible).
The „adventure”: Decisions of the „let’s do it because that’s what we usually do” variety do not stand up on their own; they require justification, and sometimes you also have to state that you are consciously accepting a certain risk rather than dealing with it immediately. (For example, because dealing with it would be more costly than the damage it might cause.)
On the positive side: The SoA and the risk register are like a map: when dealing with a new client, a new system, a new supplier, an audit or a management enquiry, you don’t have to rely on your memory – you can simply refer to them to explain why you made that decision.
What does this look like in practice?
Let’s consider a scenario where MFA (multi-factor authentication) is not currently mandatory for email accounts in the company’s MS365 environment. In such cases, there is a greater risk of account takeover, which can lead to the diversion of financial approvals and transfers (BEC), as well as the leakage of confidential company data.
- Risk owner: finance manager (business impact) and IT manager (technical responsibility).
- Decision: We manage the risk (we do not accept it).
- Action: MFA must be enabled for all accounts within 30 days; legacy authentication must be disabled; shared accounts must be discontinued.
- Responsible person / deadline: IT Manager, 30 days.
In other words, we have identified a specific risk, designated the person(s) responsible, made a decision on how to manage it, and drawn up a simple action plan with a deadline and a designated person responsible. This will be helpful later on because we haven’t just „introduced something”; it is also possible to trace why we made this decision, when it was made, who approved it, and what evidence there is to show that the control is actually working.
3) „We need to document more” – yes, but that’s what makes it scalable
What is changing? ISO 27001 requires you to manage documented information (e.g. versioning, approval, access, retention) and to be able to demonstrate that the necessary records are in place (e.g. competence, monitoring results, internal audits, management review). In practice, this introduces a „document lifecycle” approach: this makes it easy to classify what is a policy, what is a procedure, what is a work instruction, and what is simply a record (minutes, ticket, screenshot).
The „downside”: It will seem slower at first, because we’ll need to set up templates, assign responsibilities and establish a basic approval process.
On the positive side: When the company grows, new staff join or someone leaves, knowledge isn’t confined to individual minds; changes can be traced, and the audit won’t turn into a „crisis project”.
The above are just a few examples of the changes that occur within an organisation when it begins to consider ISO 27001. We have deliberately kept these descriptions general, but we hope they have helped to paint a picture of the sort of transformations you can expect if you embark on setting up and operating a system in accordance with ISO 27001.
At first glance, it may seem complex and difficult to follow, but over time it develops into a clear framework that brings order to decision-making and day-to-day operations. The benefits of this typically include not only greater security, but also faster operations, easier knowledge transfer, more stable operations and more predictable growth. If you introduce these measures step by step, your company can be placed on a more stable footing, and growth will also become much more manageable.
If you’d like to set up this process with confidence, tailored to the size and operations of your company, Manawize can help with this too: ensuring that the transformation of your processes does not remain merely „on paper”, but develops into a truly functional, stable system – whilst enabling you to make the most cost-effective and optimal decisions.
If you enjoyed the article or found the information useful, follow us on our blog and social media channels so you don’t miss out on the next instalments.
