ISO 27001:2022 ≠ A Checklist and Some Documents

ISO 27001 is often treated as a compliance project. Draft the policies, fill out the risk register, implement the controls, gather the evidence and, assuming everything is in order, collect the certificate at the end.

For a modern business, that view becomes impractical very quickly.

Companies operate across borders, rely heavily on cloud platforms, allow personal or hybrid devices, use remote developers and contractors, integrate dozens of third-party services and store information in systems they do not directly control.

ISO 27001 needs to reflect how information actually moves through that organisation. Who has access? Where does the data go? What could realistically go wrong? Who owns that risk, and how is it managed once the auditor has gone home?

The standard gives organisations a framework for managing information risk across very different operating environments. Passing an audit matters, of course, but a certificate is considerably more useful when the system behind it works on the other 364 days of the year.

---

---

1. The checklist misconception

Most people simply assume ISO 27001 is:

• A collection of security policies
• A standard set of technical controls
• Some staff training sessions  
• Evidence collected before the audit
• Certification at the end

Here’s the reality though, the standard is built around an Information Security Management System, or ISMS. The controls matter, the documents matter, but the management system around them and ensuring your staff follow them matters so much more.

I have seen technically capable organisations struggle because responsibility was unclear, nobody properly owned particular risks, or evidence and decision-making existed somewhere between several departments and a ticketing system everyone assumed somebody else was watching.

Perfect firewall rules are not much help if nobody knows who owns the change management process.

An expensive endpoint detection system is similarly decorative if nobody reviews what it tells them. Or indeed, if nobody knows the process when something is detected and some stuff hits the metaphorical fan.

In practice, ISO 27001 implementation requires decisions to be based on risk, responsibilities to be clear and evidence to form part of ordinary operations. That last part catches plenty of organisations out because evidence is often treated as something to gather for an audit rather than something the business should already be producing.

2. Security perimeters have become rather fuzzy

A modern technology environment may include staff across several countries, remote workers, contractors, developers with privileged access, BYOD, cloud infrastructure across multiple regions, SaaS applications selected by individual departments, outsourced IT, customer systems, APIs, shared repositories and several identity providers.

Information has a habit of going where the work is.

ISO 27001 therefore needs to reflect the organisation that actually exists, rather than the beautifully behaved version preserved in a network diagram from three years ago.

This is why scope and asset identification matter so much. You cannot protect an asset you do not know exists.

If the asset inventory describes a conventional internal network while the business has spent the last five years steadily accumulating cloud services, integrations and externally managed platforms, the problem starts well before the auditor arrives.

3. Scoping is one of the harder parts of implementation

Organisations sometimes try to narrow the scope because a smaller scope appears easier to certify. The boundary still has to make operational sense.

Where is customer information actually stored?

Does it pass through an analytics service before reaching your database?

Who can access production systems, and under what circumstances?

Do developers sit inside or outside the ISMS boundary based on the work they actually perform?

What happens when authorised work takes place on a personal device?

Poorly defined scope creates awkward exceptions later. Policies may describe one way of working while employees quite reasonably continue using another because that is how the business functions.

Eventually you have two organisations: the tidy one shown to the auditor and the real one everybody works in.

That arrangement rarely ages well.

One common example is the Joiner, Mover and Leaver process. HR closes an employee record on their final day. IT revokes access when the relevant ticket is processed, perhaps later that day, perhaps next week.

If nobody has agreed which event actually triggers access removal, each team can quite reasonably believe the other owns the important bit.

4. Risk assessments should describe real risks

Generic entries such as “malware infection: medium likelihood, severe impact” tell an auditor very little about the organisation in front of them.

Operational risks tend to be much more specific:

• Developer accounts retaining access after contracts end
• Credentials stored in unmanaged repositories
• Sensitive information copied to personal devices
• Production environments accessed from unmanaged endpoints
• SaaS provider outages
• Customer data moving through undocumented integrations
• Excessive permissions accumulating over time

A risk register becomes useful when it describes things that could actually happen to the organisation.

Compare the things that genuinely worry your technical or management teams with the contents of the compliance spreadsheet.

If the two bear little resemblance to one another, the spreadsheet probably needs some attention.

5. BYOD can be entirely compatible with ISO 27001

ISO 27001 does not require every organisation to issue identical, heavily controlled corporate laptops. It requires the organisation to understand the risks created by its operating model and manage them appropriately.

For BYOD, controls might include:

• Minimum device requirements
• Encryption where appropriate
• Multi-factor authentication
• Endpoint management
• Separation of business and personal data
• Restrictions on local storage
• The ability to revoke access remotely
• Privileged access controls
• Clear onboarding and offboarding processes

Leavers are where this becomes particularly interesting.

If an employee’s personal phone is still synchronising company email three weeks after they have left, the phone has not staged a coup. A process somewhere failed to tell it to stop.

The right controls depend on the organisation.

One company might require all BYOD devices to be enrolled in Mobile Device Management. Another may manage the same risk through restricted access, contractual requirements and other technical controls. What is appropriate depends on the information involved, the organisation’s risk appetite and how the business works.

Effective ISO 27001 implementation therefore starts with the organisation itself: its people, systems, suppliers and workflows.

Templates can help. They should not be allowed to design the company.

6. Developers have a very different risk profile

Developers often need access that would be entirely inappropriate for most employees.

They may work with source code, production infrastructure, credentials, databases, APIs, deployment pipelines and cloud consoles every day.

Simply removing that access is rarely a serious answer. Appropriate controls might include:

• Role-based access management
• Separation of development and production environments
• Privileged access approval workflows
• Comprehensive logging
• Secret management
• Code review requirements
• Branch protection
• Deployment approvals through pull requests
• Prompt access revocation following role changes
• Regular access reviews

The Joiner, Mover and Leaver process is again where permissions tend to accumulate.

An outsourced developer moves onto another project but retains access to the first. Removing that access requires somebody to do something, and “somebody” is a surprisingly unreliable control.

The same applies when HR records somebody as having left on Friday but IT receives the notification later. The risk sits in the period between those events and in the lack of clear ownership around them.

A good JML process therefore needs an agreed trigger, named responsibility and evidence that the action happened.

These are often the issues that appear very quickly during surveillance audits because procedures may exist on paper without being consistently recorded or tested.

Developer controls need to reflect developer work. The same principle applies throughout ISO 27001: controls should fit the risks and operational requirements of the people using them.

7. Suppliers are part of the security architecture

Few organisations control their entire technology environment.

Operations may depend on managed service providers, SaaS vendors, developers, payment processors, communication platforms, AI services, CRM systems, outsourced support and analytics platforms.

Those dependencies matter.

What happens if a critical supplier disappears?

What information can they access?

Where is that information processed?

How is their access revoked?

What security commitments exist contractually?

What evidence can they provide?

What happens to the business if their service stops working?

These are practical questions.

A payment processor outage can stop transactions. A CRM failure can leave a sales team working from memory and optimism. A critical SaaS provider can become an operational dependency long before anybody formally records it as one.

Supplier risk management is therefore part of understanding how the organisation actually operates.

8. Evidence should come from everyday operations

Weak implementations often produce a frantic evidence-gathering exercise as the audit approaches.

Access reviews appear. Vulnerability reports are located. Backup tests are reconstructed. Incident logs emerge from various corners of the organisation looking slightly surprised to have been invited.

A healthy ISMS should generate much of this evidence naturally.

Access gets reviewed because access should be reviewed.

Backups get tested because an untested backup is an interesting hypothesis.

Incidents are recorded because the organisation needs to understand what happened and what should change.

The evidence then demonstrates that the controls are working.

This makes audit preparation considerably less theatrical and, more importantly, makes the ISMS useful to the business itself.

9. AI can help, but it should not make your decisions

AI can already help with plenty of ISO 27001 work, including:

• Identifying missing information in documentation
• Mapping controls to existing evidence
• Aggregating audit logs and security findings
• Maintaining asset inventories
• Tracking supplier reviews
• Flagging overdue risk treatments
• Assisting with policy reviews
• Categorising evidence
• Finding inconsistencies between documents

Its limitations matter just as much.

AI does not own the organisation’s risk appetite. It does not automatically understand undocumented working practices or know whether your staff understands what their responsibilities are. It cannot accept risk on management’s behalf, and it cannot become accountable for a security decision because the answer arrived in a particularly confident paragraph.

Those decisions remain with management.

AI can make the management system easier to operate. Human judgement still determines which risks the organisation is prepared to accept and what should be done about them.

10. Certification is the result

Projects driven entirely by the need to pass an audit often gravitate towards documentation because documentation is visible, measurable and relatively easy to tidy.

A functioning ISMS goes further. It improves how information risk is understood and managed, with certification providing external evidence that the system meets the standard.

Good implementations can therefore look very different.

A distributed software company, manufacturer, professional services firm and retailer should not end up with identical controls. Their risks, technology and working practices are different.

The underlying discipline remains familiar: understand the risks, select appropriate controls, check that those controls work and keep improving the system.

That is where ISO 27001 becomes useful beyond the certificate hanging on the wall.

What this means for your team

If you are approaching ISO 27001 implementation, particularly in a distributed or cloud-heavy organisation, start by understanding where sensitive information lives and how it moves through the business.

That means talking to the people doing the work, not only IT or cybersecurity.

Your risk assessment should describe operational reality. Remote developers, contractors, third-party AI services and external platforms are not footnotes if they are part of normal working practice.

Evidence should also accumulate as work happens. Logging, access reviews, backup testing and incident management should create records naturally, so audit preparation becomes a matter of showing the work rather than hurriedly manufacturing a paper trail.

Developers and other specialist teams need controls that fit their jobs. Security measures that make the work impossible tend to develop mysterious workarounds shortly afterwards.

ISO 27001 works best when the business can continue being the business, only with its risks better understood, responsibilities clearer and controls that people can actually follow.

The bottom line

Strong ISO 27001 implementations will not all look alike because the organisations behind them are not alike.

They should share the same discipline: understand the risks, choose appropriate controls, demonstrate that they work and keep improving them.

A certificate proves you met the standard at audit.

A functioning ISMS is what makes that worth having.

I write about security, technology and the occasional system that has somehow survived entirely on optimism at erryn.io.