ISO 27001 Controls: What to Deploy and How to Keep Them Running

Key Takeaways

• In practice, a control needs documented evidence of repeatable operation. Auditors ask for proof that the safeguard operates and has a named owner.
• The 2022 standard reorganized 114 controls into 93 controls across four themes. Risk assessment narrows that list to what your business actually needs, documented in a Statement of Applicability (SoA).
• Governance and access management often come before endpoint tooling in lean implementations.
• After certification, governance drift creates the largest audit risk.
• If you already run CrowdStrike, Jamf or Microsoft Intune, and an identity provider, you already cover many Annex A controls. Audit success depends on documenting that coverage continuously and producing audit-ready evidence.

Procurement just sent over an email: the enterprise customer wants evidence of ISO 27001 certification or equivalent Information Security Management System (ISMS) controls before the deal closes. You have CrowdStrike on most devices, Okta handling logins, and green checks in a compliance tool. You still need to determine whether those tools form an auditable control set.

Lean teams and fractional CISOs need an ISO 27001 control set that survives certification and surveillance.

What ISO 27001 Looks Like When You Don't Have a Security Team

ISO 27001 isn't a tool you buy. It's an operating model you build: a documented set of safeguards, owners, and review rhythms that an auditor will spend days examining. The standard has 93 Annex A controls organized into four themes (organizational, people, physical, technological), but you don't implement all of them. A risk assessment narrows the list to what your business actually needs, and you document the result in a Statement of Applicability (SoA).

What you do next depends on whether you have a security operator in the building.

If you're a founder or operator without a security lead, the realistic path is to bring in a fractional or virtual CISO (vCISO) or a managed platform team. They scope your SoA, decide which controls apply, document the exclusions, and run the deployment. Trying to do this yourself usually produces a binder of policies that the auditor immediately finds gaps in. Find a fractional CISO partner at Zip Security, or talk to the team directly.

If you're a security practitioner or fractional CISO, the rest of this article is the deployment sequence, control-to-tool mapping, and post-certification cadence you need to make ISO 27001 survive certification and the surveillance years.

Both paths start with the same decision: which of the 93 controls apply, and which you can document as out of scope. Get that wrong and you either waste months implementing controls you didn't need or get flagged at audit for gaps you didn't know existed. The 2022 reorganization made that decision easier than it used to be, and it's worth understanding why.

The 2022 Standard Is Smaller Than It Looks

The 2013 edition had 114 controls across 14 domains. The 2022 revision reorganized Annex A into 93 controls across four themes, with 11 new controls introduced along the way.

Clause	Theme	Control Count	New Controls
A.5	Organizational	37	3
A.6	People	8	0
A.7	Physical	14	1
A.8	Technological	34	7
	Total	93	11

Lean teams over-index on the technical class because that's where vendors sell tools. The other three themes carry equal weight at audit time.

Seven New Controls Worth Knowing

Seven of the 11 new controls sit in A.8 (Technological). For many cloud-native teams, several of them align with work already handled through device management, endpoint protection, logging, and cloud administration.

• A.8.1 (User Endpoint Devices). Encryption, screen lock, patch compliance. The 2022 revision explicitly addresses remote working, and related guidance also discusses the use of privately owned devices.
• A.8.9 (Configuration Management). New control with no 2013 equivalent. Requires documented baselines referencing standards like CIS Benchmarks, which are published security baseline recommendations.
• A.8.12 (Data Leakage Prevention). New control requiring measures to prevent unauthorized data disclosure. Applies to data in transit, at rest, and in cloud services.
• A.8.16 (Monitoring Activities). Requires monitoring for anomalous behavior with evidence of human review. Monitoring commonly relies on logs generated under A.8.15.
• A.5.23 (Cloud Services). New organizational control covering acquisition, use, management, and exit from cloud services.

Knowing what's in the standard doesn't tell you which of the 93 controls actually apply to your business. That's the SoA's job.

The SoA Decides What You Actually Implement

Risk assessment determines what applies. The SoA records the decision for each of the 93 Annex A safeguards, with exclusions justified rather than left unaddressed. Auditors examine the SoA first, and those applicability decisions (documented for all 93) shape every audit conversation that follows.

For cloud-native startups, the exclusion side of the SoA is what makes the standard workable. Common exclusions:

• Physical safeguards can be marked not applicable when the organization has no owned premises housing information systems.
• A.8.25 through A.8.31 (Secure Development Lifecycle) apply to organizations that develop software or maintain development, test, and production environments. Exclude them where those activities don't exist.
• A.8.22 (Network Segregation) applies in cloud-native environments, and cloud controls such as VPCs and security groups can satisfy it by separating network environments rather than on-premises network hardware.

The auditor wants the reasoning documented and tied to what you selected.

A note for fractional CISOs running this work for clients: the ISACA Journal cautions that an external consultant should never formalize the SoA, because external consultants are unlikely to fully understand an organization's internal context. Each control needs to be discussed internally to create the SoA charter.

Where to Start: A Deployment Sequence That Survives Audit

Phased deployment beats simultaneous deployment. Lean teams that try to stand up every Annex A control at once end up with a binder full of policies that nothing on the network actually enforces. The sequence below takes about 12 weeks and follows the order auditors expect: governance first, identity second, endpoints third, and data protection and monitoring last. The NIST CSF 2.0 sequences Govern, Identify, and Protect ahead of Detect for the same reason.

Phase 1: Governance Foundation (Weeks 1–4)

Auditors examine governance documents before they touch a single dashboard. Without policies, named owners, and an asset inventory in place, technical controls don't have a defensible foundation. Four controls anchor this phase.

• A.5.1 (Information Security Policies). Top-level ISMS policy approved by management, with version history and staff acknowledgment records.
• A.5.2 (Roles and Responsibilities). Responsible, Accountable, Consulted, Informed (RACI) matrix with security responsibilities assigned to named internal owners. One person holding multiple roles is acceptable if segregation-of-duties conflicts (cases where one person can approve and execute the same sensitive action) are identified.
• A.5.9 (Asset Inventory). Foundation for risk assessment under Clause 6. A spreadsheet with columns for asset type, owner, classification, and last-reviewed date works. Include all SaaS apps and cloud storage.
• A.5.15 (Access Control Policy). One-page policy defining least-privilege role-based access and review cadence. This policy must demonstrably drive the technical controls you deploy next.

Phase 2: Identity and Access Management (Weeks 3–6)

The Verizon 2025 Data Breach Investigations Report (DBIR) reported that stolen credentials accounted for 22% of breaches as an initial access vector, the most common entry point. Identity controls go in early.

• A.5.16 (Identity Management). Centralize on an identity provider (Microsoft Entra ID, Okta, or Google Workspace). Document joiner/mover/leaver processes. The 2022 update broadens scope to non-human identities such as service accounts, API keys, and RPA users (automated process accounts).
• A.5.18 (Access Rights). Quarterly access reviews with management sign-off and offboarding checklists requiring prompt account revocation.
• A.8.2 (Privileged Access Rights). Separate admin accounts from daily-use accounts. Multi-factor authentication (MFA) on all privileged accounts. Document all service accounts with justification.
• A.8.5 (Secure Authentication). MFA on all cloud services, email, VPN, and admin consoles. Auditors examine MFA configuration exports and sample authentication logs.

Phase 3: Endpoint Security (Weeks 5–8)

For lean teams, mobile device management (MDM) typically goes in before endpoint detection and response (EDR), because it gives you a consistent way to enforce endpoint settings and maintain fleet visibility.

• A.8.1 (User Endpoint Devices). Enforce encryption (BitLocker/FileVault), screen lock, and patch compliance through device management.
• A.8.9 (Configuration Management). MDM compliance policies referencing CIS Benchmarks (published security baseline recommendations). Auditors examine how the baseline is defined, documented, implemented, and reviewed. Without evidence of a documented baseline for your primary OS environments, expect a nonconformity finding.

Phase 4: Data Protection, Logging, and Monitoring (Weeks 9–14)

Logging and monitoring depend on identity and endpoint controls already being in place. There's nothing useful to log from systems that don't yet enforce authentication or device compliance. By Phase 4, the prior phases have wired up the sources, and this phase makes sure the right things get captured, retained, and reviewed.

• A.8.24 (Cryptography). Policy covering data at rest (MDM-enforced disk encryption), data in transit (TLS, or Transport Layer Security), and key management lifecycle.
• A.8.15 (Logging). Audit logging in identity provider, cloud platforms, and EDR. Minimum 90-day hot retention (logs kept readily available for immediate access); 12 months total is a common operating target.
• A.8.16 (Monitoring Activities). EDR high-severity alerts and identity provider anomaly detection. Document who reviews alerts and how often. A monthly review checklist for cloud-native alerts is valid audit evidence.

By the end of week 14, the SoA is documented, governance is in place, identity and endpoints are enforced, and logging is operating. That gets you to certification. Most lean teams discover during this work that they already own the tools the deployment plan asks for.

Your Existing Tools Already Cover More Than You Think

If you're already running CrowdStrike, Jamf or Microsoft Intune, and an identity provider, you already cover many Annex A controls. Audit success depends on documenting that coverage continuously and producing audit-ready evidence.

Control	What Auditors Ask For	Primary Tool
A.8.1 (Endpoint Devices)	Encryption status, patch compliance, BYOD policy evidence	MDM + EDR
A.8.7 (Malware Protection)	EDR deployment coverage, prevention policy config	EDR + Email Security
A.8.9 (Configuration Management)	Documented baselines, CIS Benchmark reference, compliance scans	MDM
A.5.16/A.5.18 (Identity/Access)	Joiner/mover/leaver process, access review records	identity and access management (IAM)
A.8.5 (Secure Authentication)	MFA config exports, password policy enforcement	IAM
A.8.15/A.8.16 (Logging/Monitoring)	Log retention evidence, alert review records, incident response (IR) procedure link	EDR + IAM + Cloud Platforms

For teams running a mixed macOS and Windows fleet, Jamf and Microsoft Intune operate in separate consoles that don't share data natively. CrowdStrike and the identity provider add two more. Reconciling control coverage across four consoles on a cadence is what most lean teams can't sustain, and it's what makes Annex A drift accumulate between the certification audit and surveillance year two.

What Actually Breaks After Certification

Lean teams assume the technical controls will drift first. In practice, technical drift is the visible kind. The harder drift happens across the process and people work that surrounds the controls: access reviews that stop happening, asset inventories that go stale, internal audits that exist on paper but never run.

Four operational drift patterns to watch:

1. Configuration drift (A.8.9). MDM policies diverge silently as OS updates roll through and settings shift.
2. EDR agents going silent (A.8.7/A.8.16). An agent stops reporting, but neither the EDR console nor the compliance platform flags it until an auditor asks for device-level evidence.
3. Access review lapses. Teams run review cycles during the certification push, then let them lapse.
4. Log fidelity drift (A.8.15). Environment changes break log pipelines.

The 2024 Proceedings of the International Conference on Business Excellence analyzed ISO 27001 nonconformities and found that A.5 (Organizational controls) accounts for 21% of nonconformities versus 6% for A.8 (Technological controls). Technical safeguards drift visibly because they live in dashboards. Governance safeguards drift silently, unchecked until an auditor arrives.

Auditors most commonly flag four governance gaps:

• Risk assessment methodology not updated post-certification (Clause 6.1.2)
• Stale asset inventories (A.5.9)
• Excessive or orphaned access rights (A.5.15, A.8.2, A.8.3)
• Internal audit programs that exist on paper but lack evidence of execution (Clause 9.2)

The pattern across all four drift types is the same: nobody owns the cadence. Technical drift can at least be caught by automated enforcement once the tooling is wired up. Governance drift only shows up when someone is paid to look for it, and after certification day that role usually goes unfilled. ISACA notes that maintaining a certified ISMS is often harder than building it in the first place, and the reason is structural rather than technical.

Keeping the Certification Alive

ISO 27001 certification lasts three years, but auditors come back annually for surveillance audits that examine a rotating sample of Annex A controls rather than the full set. The sampling pattern is what makes drift dangerous. Weaknesses in unsampled controls can go undetected for up to two years, and surveillance auditors specifically check updated risk registers, internal audit evidence, corrective action follow-through, and proof that controls have continued to operate since the last visit.

Use this cadence to keep lean teams audit-ready year-round:

1. Quarterly access reviews with timestamped records. Access review expectations under ISO 27001, SOC 2 CC6.1, and HIPAA vary by implementation and auditor interpretation, and the available evidence does not support that a single quarterly review alone satisfies all three simultaneously.
2. Continuous configuration enforcement through mobile device management (MDM) with self-healing security and audit logging. Every logged fix should include timestamp, control, and outcome.
3. Monthly internal audit sampling rotated so full SoA coverage is achieved within each surveillance cycle.

Running this cadence year-round is where lean teams break. The work needs an owner. Most teams don't have one by year two, which is why the choice of operating model matters more than the choice of tools.

Why a BMSP Fits Here Better Than the Alternatives

Lean teams running ISO 27001 post-certification have four typical paths for keeping the technical cadence running. Each closes part of the loop. Only one closes the whole thing.

• Compliance monitoring tools: Vanta and Drata generate reports from whatever state the environment is in. If MDM policies drift or an EDR agent goes silent between audits, the report reflects the drift faithfully. A BMSP enforces the underlying controls so the reports stay true.
• Traditional MSPs: They own the licenses, run to their own playbook, and bill against ticket volume. A BMSP adds orchestration and an evidence layer on top of the existing MSP relationship.
• DIY across separate consoles: Jamf, Microsoft Intune, CrowdStrike, and Okta operate as independent tools in a fragmented stack. Managing them in parallel is the operational load that breaks lean teams 12 to 18 months after certification.
• The BMSP path (Built and Managed Security Platform): A single orchestration layer sits on top of the tools you already run, enforces the underlying controls continuously, and produces audit-ready evidence as a byproduct. Lean teams need to know what percent of their devices actually have security tools on them, and this is the model that lets them answer "all of them" and prove it.

Zip is a BMSP. It executes the deployment sequence above and keeps Annex A's technological cluster running through the three-year certification cycle. Configuration drift, agent health, and access review evidence surface in one console rather than four. What the auditor samples at surveillance year two reflects what's actually running, not what was running fourteen weeks before the certificate printed.

Finfare ran both SOC 2 and ISO 27001 on this model with a two-person IT and security team across 150+ endpoints. Audit evidence for both frameworks came from the same continuous controls, and the team stayed flat as the company grew.

A BMSP only solves the technical half of this work. The process and people side (risk reviews, training, onboarding, offboarding, internal audit cadence, role discipline) still needs a human owner. That's true whether you run it internally, hire a vCISO, or partner with an MSP. No platform fixes a missing operator.

Making ISO 27001 Work for a Lean Team

The Verizon DBIR's third-party breach rate doubled from 15% to 30% in 2025. That trajectory is why enterprise procurement teams are tightening vendor requirements, and it's why your ISO 27001 program matters to revenue rather than just audit.

Most lean teams that fail their year-two audit don't fail because they bought the wrong tools. They fail because the SoA wasn't scoped accurately, or the deployment skipped governance, or no one was watching the cadence after certification day. Certification is one day on the calendar. The surveillance years are what the program is actually built for.

Zip handles the technical half end-to-end. The rest is on whoever owns the program. Get a quote from Zip to see what that looks like in your stack.

FAQs About ISO 27001 Controls

Do you have to implement all 93 ISO 27001 controls?

No. Risk assessment determines which controls apply, and you document the results in your Statement of Applicability. All 93 must appear in the SoA with an applicability decision or exclusion justification, but you only implement the ones your risk profile requires.

Which ISO 27001 controls should lean teams start with?

Governance (A.5.1, A.5.2, A.5.9, A.5.15), then identity and access management (A.5.16, A.5.18, A.8.2, A.8.5), then endpoint and configuration controls (A.8.1, A.8.9). This sequence broadly aligns with NIST CSF 2.0, which places governance and access-related safeguards before detection-oriented activities.

Can remote or cloud-native companies exclude physical controls?

Some physical controls (such as A.7.1, A.7.4, and in some cases A.7.12) may be justifiably marked not applicable when an organization has no dedicated premises or physical infrastructure housing information systems. Document the reasoning in your SoA.

What usually breaks after certification?

Governance controls break more often than technical ones. The 2024 PICBE study found that the largest share of nonconformities was associated with Annex A.5 Organizational controls, along with A.7 Physical controls, clause 9 performance evaluation topics, and clause 6 planning topics, which together accounted for 67% of total nonconformities.

How do ISO 27001, SOC 2, and HIPAA overlap?

These frameworks share substantial overlap across access control, risk assessment, audit logging, incident response, and vendor risk management. NIST SP 800-53 Rev. 5 provides crosswalks to certain frameworks, including ISO/IEC 27001:2022, while HHS guidance points to HIPAA-related mappings and implementation references. Controls deployed for ISO 27001 can produce much of the evidence SOC 2 and HIPAA auditors want.