Skip to main content

Pro audit program · v1.0.0

ISO 27001 A.8 — Technological Controls

Endpoint, identity, network, data, dev, monitoring — A.8 in 4 minutes.

  • ISO 27001 A.8 — Technological Controls target area
  • ISO 27001 framework
  • 12 controls in this program
  • Cyentrix Cyentrix Trusted Author

About this program

Annex A.8 has 34 technological controls — the technical heart of ISO 27001. This 12-question quick check covers the highest-impact areas including the new 2022 controls (configuration management, DLP, web filtering, secure coding, monitoring). After each answer, expand the “Auditor’s view” for testing, evidence and the ideal response.

Controls (12)

  1. A.8.1 / A.8.7 — Are user endpoints protected with EDR/anti-malware, encryption and configuration management?

    Medium

    This control ensures that all user endpoints (laptops, desktops, mobile devices) are protected through three critical layers: endpoint detection and response (EDR) or anti-malware software to prevent and detect malicious code execution; full-disk or file-level encryption to protect data at…

    How to test + evidence

    Risk: EDR + FDE is the modern endpoint baseline. Configuration management ensures the baseline doesn't drift over time.

    Testing procedure: Pull EDR + MDM coverage reports. Sample 10 endpoints and verify EDR agent installed, FDE enabled, baseline configurations applied. Compare against the asset register.

    Evidence to collect: EDR coverage report (% of endpoints) MDM enrolment + compliance status FDE status report (BitLocker / FileVault) Configuration baseline document

  2. A.8.2 — Are privileged access rights restricted, just-in-time, and audited?

    Medium

    This control restricts privileged access rights to the minimum necessary personnel through role-based assignment, implements just-in-time (JIT) provisioning that grants elevated permissions only for limited time windows when needed, and maintains comprehensive audit logs of all privileged actions. Organizations deploy…

    How to test + evidence

    Risk: Persistent admin is the most-attacked control. JIT + session recording transforms standing privilege into time-bounded, auditable activity.

    Testing procedure: Request the privileged account inventory. For each: named owner, business justification, last review date. Sample 5 elevation events from the audit period — verify approval + session recording.

    Evidence to collect: Privileged account inventory with named owners PAM tooling audit logs JIT elevation request approvals Session recordings sample

  3. A.8.5 — Is authentication strong: MFA enforced, phishing-resistant where critical, no shared accounts?

    Medium

    This control requires multi-factor authentication (MFA) for all user accounts, with phishing-resistant methods (e.g., FIDO2, hardware tokens, certificate-based authentication) mandated for critical systems and privileged accounts. Shared accounts must be eliminated or reduced to exceptional circumstances with compensating controls. Strong…

    How to test + evidence

    Risk: Phishing-resistant MFA defeats AiTM attacks that bypass OTP. Auditors increasingly call out OTP-only MFA for privileged roles.

    Testing procedure: Inspect IDP conditional access policies. Pull a sample of admin + critical-system logins from the audit log — verify MFA challenge happened. Confirm legacy auth is blocked.

    Evidence to collect: Conditional access / MFA policy export Login audit log sample showing MFA Configuration showing legacy auth blocked FIDO2 / passkey deployment status for admins

  4. A.8.8 — Is technical vulnerability management mature: scanning, prioritisation, SLAs, patching cadence?

    Medium

    Technical vulnerability management is a systematic process for identifying, assessing, prioritizing, and remediating security vulnerabilities across IT assets. It encompasses automated vulnerability scanning, risk-based prioritization using scoring systems (CVSS, EPSS), defined service level agreements for remediation timelines based on severity,…

    How to test + evidence

    Risk: Risk-based prioritisation + KEV alignment is the modern bar. Patching everything-equally consumes resources without reducing risk proportionally.

    Testing procedure: Inspect the vulnerability scanner output for the period. Confirm SLAs by severity (e.g. critical 7d / high 30d). Sample 10 high-severity findings from the period and verify SLA met.

    Evidence to collect: Vulnerability management policy with SLAs Sample of scan reports (last 4 quarters) KEV catalogue subscription / monitoring Patch deployment records meeting SLA

  5. A.8.9 — Is configuration management formal: hardened baselines, drift detection? (NEW in 2022)

    Medium

    Configuration management for information systems requires formally defined hardened baseline configurations, automated drift detection mechanisms, and remediation processes. Organizations establish secure configuration standards (e.g., CIS Benchmarks, vendor hardening guides) for operating systems, databases, network devices, and applications, then deploy tools…

    How to test + evidence

    Risk: A.8.9 is new in 2022 — auditors specifically look for drift detection (not just initial baselines). Configurations drift; you need to catch it.

    Testing procedure: Inspect baseline documents (CIS Benchmarks, STIGs, vendor hardening guides). Verify drift detection tooling output and remediation records.

    Evidence to collect: Hardening baseline documents per platform CSPM / drift detection tool reports Remediation tickets for drift findings Configuration management database showing current state

  6. A.8.12 — Is data leakage prevention deployed (DLP at email/endpoint/cloud)? (NEW in 2022)

    Medium

    Data Leakage Prevention (DLP) is a suite of technologies deployed across email gateways, endpoints, and cloud services to detect and block unauthorized transmission of sensitive data based on content inspection, contextual analysis, and policy rules. DLP systems classify data (e.g.,…

    How to test + evidence

    Risk: A.8.12 is new in 2022. Email-only DLP misses cloud + endpoint exfiltration channels — auditors test for breadth of coverage.

    Testing procedure: Inspect DLP policy and rules for PII / secrets / financial data. Verify rules trigger on email + endpoint + sanctioned cloud apps. Sample DLP alerts from the period and confirm triage.

    Evidence to collect: DLP policy + active rules Sample of triggered DLP alerts with disposition Data classification labels in tooling CASB / CSPM coverage for sanctioned cloud apps

  7. A.8.13 / A.8.14 — Are backups isolated, immutable and tested, with redundancy for critical systems?

    Medium

    This control ensures that backup data is protected from ransomware, insider threats, and cascading failures through isolation from production networks, immutability mechanisms (write-once-read-many or append-only storage), and regular recovery testing. Critical systems require redundant backup copies stored in geographically separate…

    How to test + evidence

    Risk: Immutable + air-gapped defeats ransomware's most damaging move. Untested backups are an article of faith, not a control.

    Testing procedure: Inspect backup config for in-scope systems. Verify immutability (object lock or equivalent), separation from production credentials, and the most recent restore test report.

    Evidence to collect: Backup configuration (immutability flag visible) Restore test report with date + scope Backup retention policy + actual retention HA architecture diagram for critical systems

  8. A.8.15 / A.8.16 — Is logging comprehensive and are activities monitored centrally with detection content? (A.8.16 NEW)

    Medium

    This control ensures that security-relevant events across information systems, networks, applications, and infrastructure are logged comprehensively, and that logs are centralized for correlation, analysis, and real-time monitoring using detection content (rules, signatures, behavioral analytics). Logging must capture sufficient detail to…

    How to test + evidence

    Risk: A.8.16 is new in 2022 — explicit monitoring (not just logging) is now required. Logs without monitoring are forensic, not preventative.

    Testing procedure: Inspect the SIEM coverage matrix. Verify in-scope systems forward critical event types (auth, privilege, configuration). Sample alerts from the period and confirm investigation/closure.

    Evidence to collect: SIEM coverage matrix Detection rule list with last-tuned dates Sample alerts triaged with timestamps SOC roster / on-call schedule

  9. A.8.20 / A.8.22 / A.8.23 — Are networks secured with segregation, NGFW and web filtering? (A.8.23 NEW)

    Medium

    This control mandates the use of network segmentation to separate assets by trust level and function, next-generation firewalls (NGFW) to enforce layer 7 inspection and application-aware policies, and web filtering to block access to malicious or unauthorized content. Network segmentation…

    How to test + evidence

    Risk: Flat networks are a ransomware operator's dream. Auditors specifically test for east-west movement controls.

    Testing procedure: Inspect network architecture diagram + firewall rule sets. Verify segmentation between user, server, OT/IoT, DMZ tiers. Test web filter blocks a known malicious category.

    Evidence to collect: Network architecture diagram Firewall rule set + last review date Web filter category list + test result Microsegmentation policy if applicable

  10. A.8.24 — Is the use of cryptography governed by a policy, with key management?

    Medium

    This control requires the organization to adopt and enforce a formal cryptography policy that defines approved algorithms, key lengths, use cases, and operational procedures for encrypting data at rest and in transit. The policy must be supported by a key…

    How to test + evidence

    Risk: Auditors test that "encryption everywhere" is an active control with lifecycle management — not a one-off configuration that ages out.

    Testing procedure: Inspect cryptography policy and KMS access controls. Verify key rotation schedules + certificate inventory with expiry tracking.

    Evidence to collect: Cryptography policy Key inventory with rotation schedule KMS audit log showing access Certificate inventory + renewal automation

  11. A.8.25 / A.8.28 — Is there a secure development lifecycle with security testing and secure coding standards? (A.8.28 NEW)

    Medium

    This control requires organizations to implement a Secure Development Lifecycle (SDLC) incorporating security activities at every phase from requirements through deployment. Security testing includes static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), and manual…

    How to test + evidence

    Risk: A.8.28 secure coding is new in 2022 — auditors look for evidence developers receive specific secure-coding training, not just generic security awareness.

    Testing procedure: Inspect CI/CD pipeline configurations. Verify SAST + dependency scanning are required for merge. Sample pull requests showing security findings + resolution.

    Evidence to collect: CI/CD pipeline config showing security gates SAST + SCA tool reports Sample PRs with security findings + fix Secure coding training records for developers

  12. A.8.31 / A.8.32 — Is change management formal with separation of dev/test/production?

    Medium

    This control requires organizations to implement a formal change management process that enforces logical and physical separation between development, test, and production environments. Changes must follow documented procedures including authorization, testing in non-production environments, and controlled promotion through defined stages…

    How to test + evidence

    Risk: Auditors specifically check for direct-to-prod deploys (e.g. SSH onto a server and edit a file). IaC + automated deploy makes this technically impossible.

    Testing procedure: Sample 25 production changes. For each: ticket, approval, testing in non-prod, deployment record, rollback plan. Verify environments are technically separated (different accounts / VPCs).

    Evidence to collect: Change management policy Sample change tickets with full lifecycle Environment topology (dev/test/prod separated) CI/CD deploy logs tying to changes