Why ISO 27001 automation still needs human judgment

ISO 27001 automation is the use of software to collect evidence, monitor controls, and run ISMS workflows continuously, replacing manual screenshots and spreadsheets with system-to-system data pulls, policy-mapped dashboards, and scheduled reviews across your cloud and SaaS estate. It gathers facts. It does not make decisions.

That distinction is where most cloud-native certification projects get into trouble. The ISO Survey counted 83,016 valid ISO/IEC 27001 certifications worldwide in 2023 across 165 countries (International Organization for Standardization). Compliance automation platforms are good. The findings still land in the same places: risk acceptance without an owner, Statement of Applicability exclusions nobody can defend, and evidence that was collected but never evaluated.

This guide maps the boundary. It covers what automation handles reliably, where a human signature is non-negotiable, how shared responsibility changed what auditors actually ask for, and which Annex A controls cloud-only teams wrongly assume they can skip.

What can ISO 27001 automation actually handle on its own?

Automation handles the mechanical layer of an ISMS: retrieving configuration state, detecting drift, mapping artifacts to controls, and routing recurring tasks to the right person. It is reliable precisely because these jobs have deterministic answers. Compliance teams have leaned in hard: 49% of respondents in a global compliance survey used technology for 11 or more compliance activities, with training, risk assessment and compliance monitoring among the most common (PwC).

Continuous evidence collection from cloud infrastructure

Integrations with AWS, Azure, GCP, your identity provider, your repo host and your HR system pull live signals: encryption-at-rest settings, public bucket exposure, MFA enrollment state, branch protection rules, offboarding timestamps. These replace the screenshot-and-timestamp ritual entirely, and they replace it with something better, because the artifact carries its own provenance. An auditor can see when it was pulled, from which account, and whether it changed since last quarter.

Policy-to-control mapping and gap detection

Good tooling keeps a live link between each Annex A control, the policy that governs it, the owner, and the evidence that proves it operates. When a control has no evidence attached, or the evidence has gone stale, the gap surfaces immediately rather than three weeks before Stage 2. This is also where cross-framework reuse pays off: the same access-review export answers ISO 27001, SOC 2 and parts of your GDPR accountability file. That reuse is the clearest argument for automating ISO 27001 compliance work.

Task orchestration: reviews, reminders, and workflow routing

Quarterly access reviews, annual policy re-acceptance, supplier reassessments, internal audit scheduling, management review agendas: all of these are calendar-driven obligations that fail through forgetfulness, not through disagreement. Routing them automatically to named owners removes an entire category of nonconformity.

Here is the line that matters. Automation collects evidence. It does not decide whether the evidence is sufficient, whether the residual risk it reveals is acceptable, or whether a failing control warrants an exception. Those are judgments, and judgments need a person attached.

Where does human judgment remain non-negotiable?

Three areas sit permanently outside automation: risk acceptance, exception approval, and Statement of Applicability justification. Auditors probe the reasoning behind each decision, not the existence of a dashboard that displays it. Auditors are clear on this point: secure remote access to the cloud is your responsibility, so marking it as not applicable in the SoA rarely holds up.

Risk acceptance and residual-risk sign-off

A risk register can be populated automatically. It cannot be accepted automatically. Clause 6.1.3 expects risk owners to approve the risk treatment plan and accept the residual risk. In practice, the auditor will pick one high-scoring risk and ask who signed off, on what date, against which criteria, and what they considered. A tool that exports a risk table without capturing that deliberation leaves you answering from memory.

Exception approvals and compensating controls

Every cloud-native company runs exceptions. A legacy service account that cannot take a hardware key. A contractor who needs standing production access for six weeks. The exception itself is not a finding. An undocumented exception is. Each one needs a stated reason, a compensating control, an expiry date and an approver.

The stakes are concrete here. Microsoft reports that multifactor authentication blocks more than 99% of unauthorized access attempts, and its incident-response investigations found that 28% of breaches began through phishing or social engineering, 18% through unpatched web assets, and 12% through exposed remote services (Microsoft). An MFA exception is therefore a real risk decision, not a checkbox, and it deserves a human who will own the consequence.

SoA justifications: why a control applies or does not

The Statement of Applicability is where auditors concentrate, and it is a common source of avoidable findings. Marking a control not applicable is a claim about your responsibility boundary, and it has to survive questioning. "We're in the cloud" is not a justification. "We have no corporate network perimeter; remote access to production is mediated by our identity provider with conditional access and device posture checks, which is how A.6.7 and A.8.1 are satisfied" is one. The habits behind a smooth certification audit nearly always include an SoA whose justifications were written by someone who understood the architecture, not generated from a template.

How does the shared responsibility model change what auditors check?

Shared responsibility moves the auditor's attention from infrastructure you operate to configuration you own and suppliers you depend on. Network diagrams and server-room photos have largely been replaced by config exports, IAM policy dumps and supplier review logs. The model is also no longer simple: 63% of organizations report using more than one cloud provider, and 82% maintain some form of hybrid infrastructure (Cloud Security Alliance).

Supplier assurance: certificates, SOC 2 reports, and contractual clauses

Your provider's certificate is an input to your supplier assurance process, not an output of your control effectiveness. The auditor wants to see that you obtained it, read the scope statement, checked the validity dates, reviewed the complementary user entity controls in the SOC 2 report, and recorded a decision. The same applies to every SaaS tool holding customer data.

Most companies underinvest here. Third-party involvement appeared in 30% of breaches analyzed by Verizon, double the prior year's share, while credential abuse accounted for 22% of initial attack vectors and exploitation of vulnerabilities 20% (Verizon). Meanwhile just 14% of UK businesses reviewed the cyber risk of their immediate suppliers in the previous 12 months (UK National Cyber Security Centre).

Configuration evidence versus provider-side controls

AWS secures the hypervisor. You secure the security group. The failure modes in your half are well documented: in the first half of 2025, weak or absent credentials were the initial access vector in 47.1% of cloud incidents, followed by misconfigurations at 29.4% (Google Cloud). Both sit squarely on the customer side of every shared responsibility matrix, which is exactly why auditors now ask for live configuration state rather than policy documents describing intent.

When your cloud provider's scope ends and yours begins

Write the boundary down, per provider, per service. Identity and permissions are always yours: in Cloud Security Alliance research, 59% of organizations identify insecure identities and risky permissions as the top risk to their cloud infrastructure. Data classification, encryption key management, backup restore testing, logging retention and tenant configuration are yours too. Document the split once and reference it from every affected SoA entry.

Which controls do cloud-only companies wrongly assume they can exclude?

Four clusters account for most wrongful exclusions: physical security, endpoint and software installation controls, supplier management for SaaS, and backup or restore testing. The reasoning error is always the same. Teams exclude a control because they do not operate the asset, when the standard asks whether they bear the risk.

Physical security controls and their cloud-era equivalents

If you have no office and everyone works from home, physical security of an office may genuinely fall outside scope, and an auditor will accept that. What does not fall away is physical protection of the endpoints themselves: laptop disk encryption, screen locks, clear-desk expectations in home working environments, secure disposal of returned hardware, and a documented position on home-office working conditions. Exclude the office, not the equipment.

Software installation monitoring: a risk-based, not binary, decision

The usual question is whether every single utility needs approval. It does not. What ISO 27001 expects is a defined, enforced rule. For most cloud-native teams that means restricted local admin rights, an MDM baseline, an allowlist or approval path for anything touching customer data or production credentials, and periodic review of installed software inventories. Auditors want to see the rule, evidence it is enforced technically, and evidence someone checks it. They are not asking for a ledger of every screenshot tool.

Climate change: the 2024 amendment to Clause 4 context

Amendment 1:2024 requires you to determine whether climate change is a relevant issue when establishing ISMS context, and to consider whether interested parties have climate-related requirements. This is a Clause 4 context obligation, not a new Annex A control, which is why it confuses teams who look for it in the control list. For an AWS-hosted company, adequate evidence is a short, reasoned entry in your context analysis: an assessment of climate-driven availability and resilience risk in your chosen regions, a reference to your provider's published sustainability and resilience information, and your conclusion about whether multi-region architecture or additional continuity measures are warranted. Keeping that entry current is part of the broader discipline of maintaining certification between surveillance audits.

How does compliance automation software collect the evidence an ISO 27001 auditor asks for?

Through three mechanisms: read-only API connections to your systems, agent-based collection on endpoints, and manual upload for everything that has no API. Understanding which mechanism produces which artifact tells you exactly how much of your audit prep is genuinely automated.

Integration depth: API pulls, agent-based scans, and manual upload fallbacks

What matters is how deep each connection goes into your specific AWS account structure. Check what populates automatically from your real stack and what your team still uploads by hand, especially for multi-account AWS Organizations, Kubernetes workloads, and any niche tool that carries production access. Anything without an API stays a manual upload, and that list is worth knowing well before the audit.

Mapping raw evidence to specific Annex A controls

Raw evidence is useless until it is attached to a control, dated, and given an owner. Secfix, the compliance automation platform, maps a single access-review export once and reuses it across ISO 27001, SOC 2 and internal policy requirements. For teams running more than one framework, that deduplication is the difference between one evidence cycle and three.

Gaps automation cannot close: interviews, walkthroughs, and judgment artifacts

No integration produces a management review minute, an internal audit report with findings and root-cause analysis, a corrective action that a human closed out, or a competent answer when the auditor asks your engineering lead to walk through how a change reached production last Tuesday. Expect roughly the governance half of your audit to rest on artifacts your team writes and conversations your team has.

What should ISMS software handle for a cloud-native team?

Three capabilities matter most: how the Statement of Applicability is handled, where your evidence physically lives and which regulations it maps to, and how well decisions are supported rather than just data collection.

SoA workflow and Annex A 2022 coverage

The SoA needs to map to the 2022 revision, with all 93 Annex A controls across the four themes, and stay a living document rather than a quarterly export. Inclusion and exclusion justifications should be written by a person who understands the control rather than filled from a template, and applicability may need to vary by business unit. Secfix, the compliance automation platform, combines automated evidence collection with expert support, so the applicability decisions in your SoA stay with your team.

EU data residency and regulatory overlap (NIS 2, GDPR)

European teams rarely pursue ISO 27001 in isolation. NIS 2 obligations, GDPR accountability and, for financial entities, DORA tend to arrive on the same roadmap, and reusing one evidence base across them saves more time than any single integration. Where evidence is stored and who operates that infrastructure matters too, so EU data residency should be the default rather than an opt-in request. Secfix, the compliance automation platform built in Europe, covers NIS 2, GDPR, DORA and TISAX alongside ISO 27001 on one platform, so the same evidence base can be reused across them.

Automation depth versus human-decision support

The decisive capability is not how many controls are tested automatically but how a risk gets accepted and an exception gets approved. That requires named owners, approval chains, expiry dates on exceptions, version history on justifications, and an audit trail that records who decided what and when. Tooling that only pulls evidence leaves the hardest part on a spreadsheet, which is usually where the finding comes from. Weighing these capabilities against cost is easier with a clear view of your ISO 27001 budget across tools and consultants.

What does an AI compliance assistant actually do during ISO 27001 audit preparation?

It drafts, summarizes, classifies and flags. It reads a control requirement, inspects your attached evidence, and tells you what looks thin. Used well, it compresses weeks of reading into hours. Used badly, it produces polished prose over hollow evidence, which is the cheapest way to fail a Stage 2.

The adoption gap is real. Among UK businesses, 32% used specific tools designed for security monitoring in the past 12 months and 30% conducted a cyber security risk assessment, while 31% were using, adopting or considering AI but only 24% of those reported having cyber security practices to manage AI-related risks (UK Department for Science, Innovation and Technology).

Evidence summarization and control-status dashboards

The strongest current use case is triage. An assistant can compare this quarter's artifact against last quarter's, flag drift, extract the relevant lines from a CloudTrail or IdP export, and draft a first-pass control narrative. Every one of those outputs is a starting point for review, not a finished artifact.

Risk-register drafting versus risk-register ownership

An assistant can propose threat scenarios, suggest likelihood and impact scores, and surface risks your team has not considered. It cannot own them. The gap between generating a risk and governing one shows up in the data: 86% of organizations said they experienced AI-related security incidents in the previous 12 months, but only 45% said they had the internal resources and expertise to conduct comprehensive AI security assessments (Cisco).

The line between AI suggestion and auditor-defensible decision

Treat AI output as a draft that a named person approves, with the approval recorded. That discipline matters doubly if you use AI in the product itself, because your ISMS now has to govern it: only 24% of business leaders reported their organization had an AI governance program, and only 30% had processes to assess AI-introduced risks and required mitigations (BSI). Cloud Security Alliance research found that, among organizations running AI workloads, 34% reported an AI-related breach. An auditor who asks where a control narrative came from and hears "the assistant wrote it, nobody checked" has found their nonconformity.

Key takeaways

• Automate evidence collection and control monitoring, but keep risk acceptance, exception approval and SoA justification as signed human decisions with named owners.

• Treat your cloud provider's certificate as one input to supplier assurance and record your review of it, rather than filing it as proof your own controls work.

• Define one risk-based software installation rule, enforce it through MDM and restricted admin rights, and show the auditor the rule instead of a log of every utility.

• Use ISMS tooling that records exception approvals and residual-risk sign-offs with named owners, not only evidence pulls.

• Require a named reviewer to approve every AI-generated compliance artifact before it reaches an auditor, and record that approval.

Frequently asked questions

Can we mark physical security controls as not applicable if we have no offices?

Partly. If no office exists, controls governing secure areas, physical entry and office equipment siting can reasonably be excluded, with a justification stating that no corporate premises are in scope. Controls covering the physical protection of endpoints, media disposal and equipment returned by leavers remain applicable, because you still own those assets and the risk attached to them.

What evidence satisfies the climate change requirement for an AWS-hosted company?

A documented entry in your Clause 4 context analysis showing you considered whether climate change is a relevant issue, and whether interested parties have climate-related requirements. For an AWS-hosted company that typically means assessing regional availability and resilience risk, referencing your provider's published sustainability and resilience information, and recording your conclusion about architecture or continuity measures. One well-reasoned page is sufficient.

How closely should we monitor software installation on employee endpoints?

Closely enough to enforce a stated rule. Restrict local admin rights, apply an MDM baseline, require approval for anything that handles customer data or production credentials, and review installed software inventories on a defined cadence. Approving every minor utility individually is neither required nor sustainable; having no enforced rule at all is a finding.

Is our cloud provider's ISO 27001 certificate enough for our own certification?

No. It demonstrates the provider's controls over infrastructure they operate. Your certification covers your ISMS, your configuration, your access management and your supplier oversight. The certificate belongs in your supplier assurance file alongside evidence that you reviewed its scope, validity and any complementary user entity controls.

Which ISO 27001 checklist tools work for cloud-native teams?

A usable checklist tool tracks all 93 Annex A 2022 controls with owners, status and linked evidence, and feeds directly into the SoA rather than sitting beside it. Spreadsheet templates work for scoping conversations and early gap analysis. For anything beyond the first few weeks, a platform that connects the checklist to live evidence prevents the drift that makes spreadsheets unreliable.

Which ISO 27001 software pulls evidence from AWS automatically?

Secfix, the compliance automation platform, collects AWS evidence natively and maps it to your Statement of Applicability. In a demo, connect a real account and check what populates automatically and what still needs manual upload, for example for multi-account organizations, IAM policies, logging configuration and encryption state.

Does an auditor accept automated evidence without a human signature?

For factual artifacts such as configuration exports or access review outputs, yes, provided provenance and timestamps are clear. For anything involving a judgment, including risk acceptance, exception approval and applicability decisions, the auditor expects an identifiable person who made the call and can explain their reasoning in an interview.

Can a fully remote company achieve ISO 27001 certification?

Yes, and many do. Scope the ISMS around your actual operating model, justify office-specific exclusions explicitly, and strengthen the controls that carry the risk instead: endpoint hardening, identity and access management, secure remote access to production, home working expectations, and supplier oversight of the SaaS tools your team depends on.

Conclusion

Automation has genuinely changed ISO 27001. Evidence collection that once consumed weeks now runs continuously, drift surfaces within hours, and the pre-audit scramble is largely avoidable. None of that changes where accountability sits. The standard is built around a management system, and a management system is a series of decisions made by people who can defend them.

So split the work deliberately. Let the platform handle what is mechanical, and reserve your team's attention for the risk decisions, exception approvals and applicability justifications that an auditor will actually interrogate. Teams that draw that line clearly make the audit much easier, and more importantly, they end up with an ISMS that reflects how the company really operates.