Assessment against ISO/IEC 27001:2022 — Example Co Access Control Policy v0.3

Critical gaps (likely nonconformities)

• A.5.15 (Access control) — No topic-specific access control policy requirements defined: no classification-based access rules, no least-privilege or need-to-know principle stated, no segregation of internal/production access. Weak.
• A.5.16 (Identity management) — No lifecycle for identities beyond joiners/leavers: no unique IDs requirement, no handling of role changes or shared/generic accounts.
• A.5.17 (Authentication information) — Too weak: 8-character minimum is below common practice for a SaaS handling customer data (12+ recommended); no MFA requirement (critical for AWS, Workspace, GitHub); no rules on secure issuance, storage, or reset of credentials; "should not share" is not enforceable.
• A.5.18 (Access rights) — Major gaps:
  • Provisioning via a Slack channel with no formal approval, no record of authorization, no role definition ("same access as their team" is not a defined role model).
  • No periodic access review/recertification requirement.
  • No privilege access management: admin rights granted by default to "engineers who need it" with no justification, approval, or review (also relevant to A.8.2 — privileged access rights must be restricted, allocated per role, and reviewed; the founders holding super admin with no controls is a finding).
  • Removal: no defined deadline (e.g., within 24h of departure), no return of assets/revocation of tokens, keys, or MFA devices (relates to A.5.11, A.6.5).
• A.8.3 (Information access restriction) — Support staff can "view customer accounts when a customer asks" — no defined access rules, no logging of access to customer data, no restriction to read-only where appropriate.
• A.8.5 (Secure authentication) — Nothing beyond passwords: no MFA, no secure authentication technology requirements, no handling of re-authentication for sensitive actions.

Gaps for A.8.2 (Privileged access rights)

• No inventory of privileged accounts, no restriction of admin use to dedicated accounts, no just-in-time or approval process, no logging/monitoring of privileged sessions (also ties to A.8.15).

Other weaknesses worth flagging

• No review cycle, version control/approval process (policy is an unapproved draft — relevant to A.5.1 and clause 7.5).
• No link to role definitions or a responsibility matrix (A.5.2).
• No mention of contractors' access expiry or NDAs (A.6.6, A.5.19 context).
• No incident process for lost credentials or suspicious access.

Prioritized fixes for audit readiness

1. Add MFA for all admin and remote access (A.8.5, A.5.17).
2. Define roles with access profiles; formal approval and recorded authorization for grants (A.5.18).
3. Introduce quarterly access reviews, especially for privileged accounts (A.5.18, A.8.2).
4. Set a leaver SLA (e.g., revoke within 1 business day) and cover tokens/MFA devices (A.5.18, A.6.5).
5. Restrict and monitor admin access; require justification per engineer (A.8.2).
6. Restrict and log support staff access to customer data (A.8.3).

Note: this policy covers only Annex A controls; for clause compliance it should also reference the ISMS risk assessment and be formally approved by management.

Statement of Applicability — Exclusion Justifications (ISO/IEC 27001:2022, Annex A)

Organization context: Fully remote SaaS company (25 staff, no office premises), infrastructure hosted on AWS.

Justification basis: Clause 6.1.3(d) — controls deemed not applicable where they do not affect the organization's ability to satisfy the security requirements determined by its risk assessment. Exclusions do not reduce the ability to meet identified security requirements.

---

A.7.1 — Physical security perimeters

Status: Not applicable Justification: The organization operates no physical premises. All employees work from personal home locations, and all production infrastructure resides in AWS data centers, where perimeters are managed and controlled by AWS under the AWS ISO 27001 / SOC 2 certified shared responsibility model. No assets under the organization's direct control require a physical perimeter. No identified risk in the risk register is dependent on physical perimeter demarcation.

A.7.2 — Physical entry

Status: Not applicable Justification: The organization controls no facilities to which physical entry would be restricted. There are no server rooms, data centers, or office spaces owned or leased by the organization. Access to production systems is logical, governed by A.5.15–A.5.18 (access control and access rights) and AWS IAM. Physical access to underlying AWS facilities is inherited from AWS and covered by the cloud services control (A.5.23) and supplier agreements (A.5.20).

A.7.3 — Securing offices, rooms and facilities

Status: Not applicable Justification: No offices, rooms, or facilities exist to secure. The corresponding risk treatment decision is that no residual physical-environment risk remains within organizational responsibility once AWS physical security is inherited.

A.7.4 — Physical security monitoring

Status: Not applicable Justification: The organization has no physical areas requiring monitoring. Security monitoring is performed at the logical layer (A.8.15 Logging, A.8.16 Monitoring activities) and includes detection of suspicious access patterns, which addresses the underlying intent of this control. Physical monitoring of AWS facilities is AWS's responsibility under the shared responsibility model.

---

What an auditor will still check

1. Scope statement consistency: Your ISMS scope (clause 4.3) must explicitly describe the remote/no-premises model. Any mismatch between the scope, risk assessment, and SoA exclusions is a common finding.
2. Risk assessment evidence: The exclusions must trace back to your risk assessment — show that physical risks were actually considered and assessed, not silently skipped. Auditors often look for an entry (even "accepted/inherited") for physical risks.
3. Shared responsibility documentation: Cloud services agreement with AWS (A.5.23), supplier security clauses (A.5.19/A.5.20), and evidence you reviewed AWS's certifications (ISO 27001/SOC 2 reports) and understand your responsibilities in the shared model.
4. Remote work controls: A.6.7 (remote working) must be fully applied — home working guidance, device security (A.8.1), endpoint encryption. Expect auditor interviews with remote employees.
5. Off-premises asset security: A.7.9 remains applicable (laptops, phones taken home — loss/theft scenarios), as does A.7.10 (storage media), A.7.14 (disposal of equipment), and A.7.7 adapted to remote context (clear screen at home).
6. No compensating gap: Auditors verify the exclusions don't leave an unaddressed risk — e.g., physical theft of endpoints should be covered by A.7.9, disk encryption, and MDM. Be ready to show that chain.
7. SoA governance: The exclusion decision must be approved by management, documented with date/owner, and re-validated if circumstances change (e.g., opening a co-working space).

Practical tip: Keep A.7.5–A.7.14 applicable with remote-work adaptations rather than excluding them — this shows auditors you thought through the physical layer rather than deleting it.

Disagreements an auditor would raise

1. Backup contradicted (8.13) — SoA excludes 8.13 as "handled by AWS," but R-01 treats data-loss risk using 8.13, with a planned treatment. An auditor sees an applicable control marked not applicable. Fix: mark 8.13 applicable, justify it as "managed via AWS snapshots with quarterly restore testing" (shared responsibility still requires you to verify it), or exclude it and re-treat R-01 with a different, existing control — with the exclusion justified in the risk assessment.

2. Cloud baseline claimed implemented but risks not treated (5.23) — SoA says 5.23 is implemented; R-03 says the configuration baseline and monitoring are "Planned." Fix: align — either downgrade SoA status to "Partially implemented / Planned" with a remediation date, or complete the baseline work and update R-03.

3. Monitoring control in register but missing from SoA (8.16) — R-06 relies on 8.16 Monitoring, which doesn't appear in the SoA extract. Fix: add 8.16 with status and justification, or remove it from R-06 and fold monitoring into 8.15's scope.

4. Supply chain control in register but missing from SoA (5.21) — R-02 references 5.21 ICT supply chain; SoA only lists 5.19. Fix: add 5.21 to the SoA or limit R-02's controls to 5.19.

5. Supplier treatment "in progress" vs "implemented" (5.19) — SoA claims 5.19 implemented; R-02's questionnaire is only drafted, so the control isn't demonstrably operating for all suppliers. Fix: mark 5.19 "Partially implemented" or finish the review cycle before certification.

6. Acceptance of R-05 lacks documented justification — "Accepted by CEO" alone is weak; ISO 27001 clause 6.1.3 and A.5.29/A.5.30 context expect acceptance criteria, justification, and periodic review. Also note 5.30 is "Implemented" (yearly continuity test) while the regional-outage risk is accepted with no controls — auditors will ask how a tested continuity plan supports an unmitigated risk. Fix: record acceptance rationale, review date, and link the continuity test to R-05.

7. "Planned" treatments for high-impact risks with no dates — R-01, R-03, R-06 are Medium/High with unplanned remediation. Fix: add target dates, owners confirmed, and track them via clause 8.3 and 10.2; auditors expect a risk treatment plan, not just status labels.

8. Version/date governance — SoA v1.2 vs register 2026-Q3 with no explicit cross-reference. Fix: state in the SoA that it derives from risk assessment results (clause 6.1.3 requires applicability to be justified by risk treatment), and keep both synchronized per change.

One-line assumption: the SoA extract is complete for the controls cited in the register; if controls like 8.16/5.21 exist elsewhere in the full SoA, items 3–4 dissolve.