ISO 27001 for Cybersecurity Teams: Controls, Risk Treatment and Integration

If you own security at your organization and ISO 27001 has landed on your desk, your questions are different from the ones your leadership is asking. They want to know cost and timeline. You want to know what the standard actually demands of your security program: which Annex A controls apply, how risk treatment decisions get documented and defended, and how much of the security work you've already done (SOC 2 evidence, NIST CSF alignment, existing access controls) carries over.

I've worked with organizations across healthcare, SaaS, financial services, and manufacturing to earn ISO 27001 certification, and the pattern I see most often is this: teams spend six months building policies, then spend audit week realizing that documentation and implementation are two completely different things. The auditor isn't checking your binders. They're checking whether your people live by what's in them.

This guide covers the security-program side of ISO 27001: what the standard requires of your controls, what changed in the 2022 revision, how to run risk treatment and build a defensible Statement of Applicability, and how the ISMS integrates with the security frameworks you already run. For the process side, meaning audit stages, timelines, and costs, see our ISO 27001 certification process guide.

What ISO 27001 Actually Requires

ISO/IEC 27001 is an international standard for Information Security Management Systems. The core of the standard isn't a checklist — it's a management framework. Clauses 4 through 10 of ISO 27001:2022 define how your organization should establish, implement, maintain, and continually improve an ISMS. Annex A then provides a reference set of 93 controls you can select based on your risk assessment.

That phrase — "based on your risk assessment" — is where most organizations underestimate the work. ISO 27001:2022 clause 6.1.2 requires organizations to identify information security risks against criteria established by the organization itself, which means there is no universal right answer for which risks to document and no template that replaces genuine judgment. The standard is intentionally flexible, and auditors are trained to tell the difference between an organization that understood its actual risk environment and one that filled out a downloaded template.

The Annex A controls cover four categories in the 2022 revision: organizational controls, people controls, physical controls, and technological controls. That's a structural simplification from the 2013 version's 14 domains — but the underlying security expectations are more demanding in several areas, particularly around supply chain risk management, cloud services, and threat intelligence.

What Changed in ISO 27001:2022 (and Why It Matters Now)

The 2022 revision is not a cosmetic update. The International Accreditation Forum mandated a transition deadline of October 31, 2025, which means any certificate still issued under the 2013 version is now expired. If your organization holds an old certificate and hasn't transitioned, you're operating with a lapsed certification — a fact that surfaces quickly in enterprise due diligence.

The most consequential changes:

Annex A restructured. Down from 114 controls in 14 domains to 93 controls in 4 themes. Eleven controls are entirely new, concentrated in areas most organizations have historically underinvested in: threat intelligence (control 5.7), information security for cloud services (5.23), data leakage prevention (8.12), and data masking (8.11).

Context and scope are harder to game. Auditors in 2025–2026 are more sophisticated about clause 4.1 and 4.2 requirements. A vague scope statement that quietly excludes your most sensitive systems without documented justification will generate a nonconformity. I've seen this exact issue close what should have been a clean Stage 1.

Attribute taxonomy. The 2022 revision introduced optional attributes — preventive, detective, corrective, and others — to each Annex A control. It's not mandatory, but auditors have started noticing whether organizations have thought about it, and it signals the difference between an ISMS built to pass and one built to function.

Organizations that pursued the 2022 certification rather than delaying came out ahead, both because the auditor pool is now fully calibrated to the new standard and because the revised Annex A maps considerably better to modern cloud and SaaS environments than the 2013 version ever did.

The Annex A Control Themes: Where the Implementation Work Lives

The 93 Annex A controls are organized into four themes, and each demands a different kind of evidence. Knowing where your program is strong and where it is thin before you start saves months.

Organizational controls (37 controls). This is the largest theme and the one security teams most often underestimate, because much of it lives outside the security function: supplier security requirements (5.19–5.22), threat intelligence (5.7), cloud service security (5.23), and incident management. The evidence auditors want here is process evidence: signed supplier agreements with security clauses, documented intelligence feeds actually reviewed, incident tickets with closure records.

People controls (8 controls). Screening, terms of employment, awareness training, disciplinary process, and responsibilities after termination. Small in count, heavily sampled in audits. If your offboarding checklist doesn't provably revoke access on the last day of employment, expect a finding.

Physical controls (14 controls). For cloud-native companies these often reduce to office access, equipment disposal, and clear-desk practice, with data center controls inherited from your cloud provider. Document the inheritance explicitly; "AWS handles that" is not evidence, but AWS's SOC 2 report mapped to the relevant controls is.

Technological controls (34 controls). Access control, cryptography, logging and monitoring, configuration management, secure development, and the 2022 additions: data leakage prevention (8.12), data masking (8.11), and web filtering (8.23). Most security teams have real capability here already. The gap is rarely the tooling. It's the documented standard behind the tooling and the records showing the standard is enforced.

Risk Treatment and the Statement of Applicability

The risk assessment produces a register. Risk treatment is what you do about it, and clause 6.1.3 gives you four options for each risk: modify it with controls, accept it, avoid it, or share it. Every treatment decision needs documented justification, and the decisions roll up into the single most-scrutinized document in the entire audit: the Statement of Applicability.

The SoA lists all 93 Annex A controls with a justification for each inclusion or exclusion. This is where security judgment gets tested. Excluding a control because it genuinely doesn't apply to your environment is fine. Excluding it because implementing it would be inconvenient is a nonconformity waiting to be written. Marking a risk "accepted" without a documented rationale signed by someone with the authority to accept it is another.

The Stage 2 findings I see most often all trace back to this layer:

• Controls listed in the Statement of Applicability with no corresponding evidence of operation
• Risk treatments marked "accepted" without documented justification
• Asset inventories that haven't been maintained since the initial build
• Supplier agreements that don't include security requirements (control 5.19 requires them)
• Incident response procedures that exist on paper but haven't been tested

Notice the pattern: none of these are missing-document problems. They're all gaps between what the ISMS claims and what the security program actually does. A defensible SoA is built from the risk register outward, not from a template inward.

How ISO 27001 Fits the Security Frameworks You Already Run

One of the most common questions I get is how ISO 27001 relates to SOC 2 or NIST, and how much of that existing work carries over. The honest answer is that it depends on your customer base and regulatory context — and in many cases, the right answer is more than one framework running on shared evidence.

ISO 27001 is the right choice when your customers are outside North America, when you're entering regulated markets, or when you need a certification — not just an attestation — that carries third-party accreditation. SOC 2 serves a different market. I've seen organizations spend 18 months on SOC 2 only to discover their target enterprise clients in Europe require ISO 27001. The two aren't interchangeable even though they cover overlapping ground.

The good news for teams with existing programs is that the overlap is real and reusable:

From SOC 2. A mature SOC 2 Type II program has already produced most of the operating evidence ISO 27001 wants: access reviews, change management records, vendor assessments, incident tickets. What SOC 2 hasn't produced is the management system layer: the risk assessment methodology, the Statement of Applicability, internal audit, and management review. Map your Trust Services Criteria evidence to Annex A once, and you avoid running two parallel evidence pipelines.

From NIST CSF. The CSF's functions map cleanly onto Annex A's themes, and a completed CSF self-assessment is a strong input to the ISO 27001 gap assessment. The difference is enforcement: CSF is a self-directed framework, while ISO 27001 subjects the same territory to third-party audit against your own documented criteria.

From CMMC / SP 800-171. If you're in the defense supply chain, the control overlap on access control, media protection, and incident response is substantial, but scope boundaries differ. CUI enclaves and ISMS scope statements need to be reconciled deliberately, not assumed to coincide.

The integration principle that holds across all of these: build one control set, one evidence repository, and one risk register, then let each framework draw from it. Organizations that run frameworks as separate projects pay for the same work twice and drift out of sync within a year.

I'll say this plainly, because it applies no matter which frameworks you're combining: if your executive team isn't visibly involved in the ISMS, you will struggle in the Stage 2 audit. Clause 5.1 of ISO 27001:2022 requires demonstrable leadership commitment, and auditors who've been doing this for years can tell the difference between a CEO who understands the scope of the ISMS and one who signed a policy without reading it.

What the Data Says About ISO 27001 and Cybersecurity Risk

A few statistics worth knowing before your next leadership conversation about certification:

The IBM Cost of a Data Breach Report 2024 puts the average cost of a data breach at $4.88 million, a 10% increase over the prior year. Organizations with mature security compliance programs consistently show lower breach costs than those without — and the gap has been widening, not closing.

As of the most recent ISO Survey, 70,969 ISO/IEC 27001 certificates had been issued across 150+ countries, a number that has grown by double digits year-over-year as enterprise procurement teams add certification requirements to vendor qualification checklists. The North American growth rate is accelerating faster than any other region.

The 2022 revision's 11 new controls are concentrated in exactly the areas where most organizations have the largest gaps: threat intelligence, cloud security, data leakage prevention, and secure coding. The October 2025 IAF transition deadline means any ISO/IEC 27001:2013 certificate is now expired; organizations seeking first-time certification must pursue the 2022 standard. There is no path to a valid certificate through the old version.

Supply chain compromise has become the attack vector of choice for sophisticated threat actors, which is a direct driver of why ISO 27001 control 5.19 — information security in supplier relationships — has become one of the most scrutinized areas in recent certification audits. The organizations that treat supplier security as a paperwork exercise rather than a real assessment process are the ones generating nonconformities here.

What to Look for in an ISO 27001 Cybersecurity Consultant

If you're considering external help — and most mid-size organizations benefit from it — here's what I'd actually evaluate.

First, ask whether they've led organizations through Stage 2 audits, not just built documentation. Documentation is the straightforward part. The harder work is preparing your team for auditor interviews, ensuring controls are genuinely operating, and running a credible internal audit before the external auditor arrives. A consultant who has only ever built paper programs will leave you exposed at the moment it matters most.

Second, ask about their familiarity with your industry. ISO 27001 is an industry-agnostic standard, but the risk landscape varies considerably between a SaaS company handling customer PII and a medical device manufacturer subject to FDA 21 CFR Part 11. The controls you select and justify should reflect your actual environment, not a generic Annex A template pulled from the internet.

Third — and this is the one most people skip — ask how they handle nonconformities. A consultant who guarantees a clean audit is telling you what you want to hear, not what you need to know. The realistic expectation is that your Stage 1 will generate observations and possibly minor findings, and a good consultant has a clear process for resolving them before Stage 2.

At Certify Consulting, we've maintained a 100% first-time audit pass rate across more than 200 client engagements over eight-plus years. That number holds because we don't advance clients to Stage 1 until we'd stake our own reputation on the readiness of their documentation — and we don't advance to Stage 2 until the internal audit has been genuinely stress-tested, not just checked off. If you're trying to figure out what ISO 27001 certification would actually require for your organization, I'm happy to talk through it before you commit to a path. Reach out at certify.consulting.

Where to Go From Here

If the control themes, risk treatment mechanics, and framework mappings above describe work your team can see itself doing, the next step is sequencing it. Audit stages, realistic timelines, budget ranges, and the step-by-step path from gap assessment to certificate are covered in our ISO 27001 certification process guide.

One budgeting note belongs here rather than there, because it lands on the security team: the real cost driver isn't the consultant fee or the certification body fee. It's the internal staff time required to implement controls that actually operate and to produce the objective evidence auditors will ask for. Organizations that underestimate this consistently run over budget and over schedule, and the shortfall almost always shows up in the technological and organizational control themes described above.

Jared Clark is Principal Consultant at Certify Consulting, where he leads information security and quality management certification engagements for organizations across the U.S. and internationally. He holds credentials including JD, MBA, PMP, CMQ-OE, CQA, CPGP, and RAC, and has served 200+ clients with a 100% first-time audit pass rate over eight-plus years of practice.

Last updated: 2026-06-14