🔵 A.5 – Organisational Controls (Engineer-Relevant Only)

---

A.5.7 – Threat Intelligence

What this control means:
The organisation must gather, analyse, and apply threat intelligence to support detection, response, and decision-making. This includes intel on emerging vulnerabilities, attack techniques, industry-specific threats, insider risks, and supply-chain hazards. The key point is that threat intel must be operationalised, not just consumed.

How to implement it:
A Senior Cyber Engineer should ensure that threat intelligence feeds flow into actionable pipelines (SIEM rules, MDR triage logic, automated enrichment, alert tuning). Engineers should correlate intel with internal telemetry (IAM logs, EDR alerts, cloud events) to produce new detections and hardening recommendations. There should also be a documented lifecycle for reviewing threat intel and updating controls.

Real-world examples:

• Consuming MISP/OTX feeds and auto-enriching IOC detections in the SIEM.
• Updating cloud alert rules after a surge in OAuth token phishing attacks.
• Creating a SOAR playbook that checks external TI feeds for indicators seen in firewall logs.

---

A.5.9 – Inventory of Information and Other Associated Assets

What this control means:
Organisations must maintain an up-to-date inventory of all information assets, including data stores, applications, hosts, APIs, cloud resources, and SaaS services. For engineers, this means the infrastructure you secure must be known, catalogued, and classified.

How to implement it:
A Senior Cyber Engineer should integrate automated asset discovery tools (CSPM, CMDB, endpoint inventory, API gateways) to keep inventories fresh. The inventory must include metadata such as data sensitivity, owner, environment, and security controls applied (MFA, encryption, logging). Automation is essential; manual inventories always rot.

Real-world examples:

• CSPM automatically discovering new AWS IAM roles or S3 buckets.
• EDR agents auto-registering devices into the CMDB.
• API gateways tagging all exposed endpoints with classification labels.

---

A.5.12 – Classification of Information

What this control means:
Information must be categorised based on sensitivity and impact (e.g., Public – Internal – Confidential – Restricted). Proper classification ensures appropriate security controls such as encryption, access restrictions, or DLP rules.

How to implement it:
Engineers should embed classification into data workflows: tag datasets in cloud storage, enforce classification labels in productivity suites, and use DLP/retention controls that respond to labels. Automated pipelines should propagate classification metadata so that data cannot silently move into weaker environments.

Real-world examples:

• Azure Information Protection auto-labelling documents containing PII.
• S3 bucket tags indicating “Contains Restricted Data: Encryption Required”.
• Classification-aware DLP rules blocking uploads of “Confidential” files to unmanaged apps.

---

A.5.17 – Information Security Requirements in Project Management

What this control means:
Security must be considered at every stage of internal projects, whether software development, SaaS onboarding, cloud architecture, or infrastructure upgrades. Security cannot be bolted on later — it must be a formal step in project planning.

How to implement it:
A Senior Cyber Engineer should integrate structured security reviews into project workflows: threat models, architecture reviews, code scanning gates, IaC validation, and mandatory SSO/MFA enforcement for new services. This involves working closely with engineering, IT, and PM teams to define security milestones in project plans.

Real-world examples:

• Cloud projects requiring an architecture diagram and CSPM scan before deployment.
• SaaS onboarding requiring SSO, logging, and contract security reviews.
• CI/CD pipelines enforcing SAST/SCA scans before builds can deploy.

---

A.5.18 – Inventory of Cloud Services

What this control means:
Cloud services (IaaS, PaaS, SaaS) must be identified, documented, risk-assessed, and governed. Shadow IT must be minimised; organisations cannot protect what they don’t know exists.

How to implement it:
Engineers should use CASB, DNS inspection, CSPM, and identity logs to discover unknown cloud use. Approved services should be tagged, monitored, logged, and reviewed periodically. The inventory should include data types processed, authentication method used, region, encryption, and compliance posture.

Real-world examples:

• CASB alerting on unapproved storage apps being used by staff.
• Terraform automatically tagging deployed cloud resources with metadata.
• SaaS registry showing whether each app supports SSO, SCIM, encryption, and admin logging.

---

A.5.19 – Configuration Management

What this control means:
Technical configurations must be standardised, controlled, and documented across environments. This mitigates drift, misconfigurations, and inconsistent security baselines.

How to implement it:
Engineers must define and enforce hardened baselines (CIS, NCSC, STIG). Automation tools like Ansible, Intune, MDM, Terraform, and GitOps pipelines should apply consistent configurations. Drift detection should alert when environments deviate from the baseline.

Real-world examples:

• Intune enforcing BitLocker, firewall, and update baselines.
• Terraform managing cloud network policies across environments.
• CIS benchmark scans ensuring OS-level hardening is consistently applied.

---

A.5.23 – Information Security for Use of Cloud Services

What this control means:
Cloud services must be appropriately secured, monitored, configured, and governed throughout their lifecycle. This includes selection, onboarding, configuration, monitoring, and offboarding.

How to implement it:
A Senior Cyber Engineer should ensure SSO/MFA, encryption, logging, admin role restrictions, and network protections are applied to every cloud service. CSPM tools should continuously evaluate posture, while IaC pipelines enforce secure defaults. Security reviews must be mandatory before new cloud services go live.

Real-world examples:

• Enforcing MFA + SSO for all SaaS tools.
• Enabling CloudTrail/AzureActivity monitoring for all cloud accounts.
• CSPM detecting public S3 buckets or overly permissive IAM roles.

---

A.5.30 – ICT Supply Chain Security

What this control means:
Vendors and third-party services must be assessed for security risks, monitored, and governed. Any service that processes your data must meet your security expectations.

How to implement it:
Engineers should validate vendor security documentation (pen tests, SOC2, ISO27001), enforce SSO, and ensure logging/integration points are secured. Technical checks must include data flow analysis, API security, admin access restrictions, and monitoring integrations. Vendor risk must feed into incident response.

Real-world examples:

• Evaluating whether a SaaS provider supports audit logs and immutable backups.
• Blocking vendors that cannot integrate with SSO or export logs.
• Automated risk scoring platforms (SecurityScorecard, Bitsight) flagging emerging vendor exposures.

---

A.5.36 – Technical Compliance Review

What this control means:
Infrastructure and applications must be periodically reviewed for compliance with policies, standards, and regulatory requirements. This ensures systems remain aligned with security baselines.

How to implement it:
A Senior Cyber Engineer should run periodic automated audits using CSPM, vulnerability scanners, endpoint compliance tools, code-quality tools, and configuration scanners. Findings should drive remediation tasks in ticketing systems and feed into risk assessments.

Real-world examples:

• Monthly CIS compliance scans on servers.
• Reviewing cloud IAM roles for excessive permissions.
• Checking firewall rules for drift or shadow policies.

🔵 A.7 – Physical Controls (Engineer-Relevant)

---

A.7.10 – Secure Disposal or Re-use of Equipment

What this control means:
Any device or media containing organisational data must be securely wiped or destroyed before reuse, recycling, or disposal. This includes laptops, servers, disks, mobile devices, cloud-hosted volumes, removable storage, and virtual machine instances. The goal is to prevent data leakage from decomissioned systems.

How to implement it:
A Senior Cyber Engineer must ensure wiping processes are automated and verifiable, with logs or certificates of destruction stored for audit. Cloud platforms require secure deletion of snapshots, storage blocks, and orphaned volumes. Wipe scripts should follow NIST standards, and any hardware that cannot be reliably wiped must be physically destroyed. Engineers must ensure that backup copies and log archives are also sanitised when retired.

Real-world examples:

• Automatically wiping cloud disks via IaC during VM tear-down.
• Using BitLocker key revocation and drive re-encryption before laptop reuse.
• Hardware shredding of failed SSD drives with certificates stored in a ticketing system.

---

🔵 A.8 – Technological Controls

This is the core section for a Senior Cyber Engineer.

---

🆔 Identity, Access & Authentication Controls

---

A.8.1 – User Endpoint Devices

What this control means:
Endpoint devices must be configured and secured to reduce risk from malware, data loss, or unauthorised access. This applies to desktops, laptops, mobile devices, and even virtual desktops. A minimum baseline of hardening must be enforced.

How to implement it:
Engineers should deploy EDR tools, enforce disk encryption, block unauthorised USB devices, apply OS baseline hardening, and ensure patching is automated. Endpoint compliance should feed into conditional access policies so non-compliant devices cannot access corporate resources.

Real-world examples:

• Intune forcing BitLocker + firewall + Defender EDR.
• Blocking admin rights on all laptops except break-glass accounts.
• MDM enforcing minimum OS version on mobile devices.

---

A.8.2 – Privileged Access Rights

What this control means:
Privileged accounts (admins, root, domain admins, cloud IAM admins) must be tightly controlled, monitored, and protected. These are the highest-value targets.

How to implement it:
Engineers should implement PAM (privileged access management), enforce just-in-time elevation, use dedicated admin accounts, require MFA with hardware tokens, and restrict admin access to hardened jump hosts. All privileged actions must be logged to a SIEM. No engineer should use a normal user account with persistent admin rights.

Real-world examples:

• Azure PIM for just-in-time cloud IAM elevation.
• Domain admin accounts that cannot log in to workstations.
• Break-glass accounts stored in sealed envelopes or password vaults.

---

A.8.3 – Information Access Restrictions

What this control means:
Users should only access the data required for their role. Access must be governed by RBAC, least privilege, and segregation of duties.

How to implement it:
A Senior Cyber Engineer should enforce RBAC across cloud resources, apply ACLs consistently, and prevent shared accounts. Automation must ensure access is provisioned and revoked automatically upon role change. Sensitive datasets must be protected with DLP, encryption, and monitoring.

Real-world examples:

• Using Azure RBAC to restrict access to specific Key Vault secrets.
• IAM roles that limit S3 access to specific prefixes.
• Blocking engineers from accessing production data unless explicitly approved.

---

A.8.4 – Secure Authentication

What this control means:
Authentication mechanisms must be robust and resistant to compromise. MFA should be mandatory, passwordless preferred, and legacy protocols disabled.

How to implement it:
Engineers should enforce MFA across all services, implement conditional access, deploy hardware authentication (FIDO2 keys), remove weak protocols (IMAP, POP3, NTLM), and require strong client apps. Cloud authentication logs must be monitored for anomalies.

Real-world examples:

• Blocking non-MFA logins by policy.
• Enforcing FIDO2 keys for all admin accounts.
• Using Impossible Travel detections in Azure AD/Okta.

---

A.8.5 – Capacity Management

What this control means:
Systems must be designed to handle expected load, avoiding outages due to resource exhaustion (CPU, RAM, storage, bandwidth). This includes autoscaling cloud environments.

How to implement it:
Engineers should use observability tools to monitor resource usage, set thresholds, enable autoscaling, and plan capacity based on load testing. Cloud workloads must have alerts for performance degradation, and logs should feed into monitoring dashboards.

Real-world examples:

• Auto-scaling policy in AWS Lambda or Kubernetes HPA.
• Alerts when storage reaches 80% capacity.
• Dashboards showing CPU and memory trends for servers.

---

🛡 Endpoint & Malware Controls

---

A.8.6 – Protection Against Malware

What this control means:
Systems must be protected from viruses, ransomware, trojans, worms, and malicious scripts. Protection must be proactive, not reactive.

How to implement it:
Deploy EDR across all endpoints, enforce real-time scanning, enable script control, block unsigned executables, and integrate alerts into the SIEM. Cloud workloads should use anti-malware agents or managed threat services. Email and web filtering should block malicious content at the boundary.

Real-world examples:

• EDR detecting PowerShell exploitation attempts.
• Blocking macros from untrusted sources in Office apps.
• Email filtering sandboxing attachments.

---

A.8.7 – Management of Technical Vulnerabilities

What this control means:
Vulnerabilities must be identified, prioritised, and remediated in a timely manner. This includes OS patches, application updates, and cloud misconfigurations.

How to implement it:
Engineers must run continuous vulnerability scans, integrate patch automation, triage findings by severity, and ensure remediation SLAs exist (e.g., Critical: 7 days). Cloud issues discovered by CSPM tools must be tracked and resolved. Vulnerability trends must feed into risk analysis.

Real-world examples:

• Weekly Nessus/Qualys scans.
• CSPM identifying exposed public cloud storage buckets.
• Automated patching windows for servers and containers.

---

A.8.8 – Configuration Management

What this control means:
Systems must follow a consistent baseline configuration to avoid insecure drift. Hardening is essential.

How to implement it:
Use IaC (Terraform/Ansible) to enforce consistent configurations. Use MDT/Intune/MDM for endpoints. Run regular CIS scans and remediate drift. All configurations must be version controlled.

Real-world examples:

• Terraform enforcing network rules across multiple environments.
• CIS-L1 hardening applied to Linux servers.
• Drift detection triggering Slack or Teams alerts.

---

🧪 Development, AppSec & SDLC Controls

---

A.8.9 – Information Security in Development Processes

What this control means:
Security must be embedded throughout the development process, including design, coding, testing, and deployment.

How to implement it:
Engineers should implement SAST, SCA, DAST, IaC scanning, dependency checking, secrets detection, and code reviews. Build pipelines must enforce minimum security gates. Sensitive data should never be used in lower environments unless masked.

Real-world examples:

• GitLab CI blocking merges with high-severity SAST issues.
• Checkov scanning Terraform before apply.
• Secrets detectors blocking commits containing keys.

---

A.8.10 – Secure Coding

What this control means:
Code must be written following secure coding principles to prevent XSS, SQL injection, CSRF, deserialisation attacks, and other vulnerabilities.

How to implement it:
Create internal secure coding guidelines, provide developer training, and enforce standards via code reviews and automated scanning tools. Use frameworks that provide built-in protections and limit direct handling of unsafe input.

Real-world examples:

• Using parameterised queries instead of raw SQL.
• Sanitising user input before rendering.
• Mandatory peer reviews for all backend API changes.

---

A.8.11 – Testing in Development and Acceptance

What this control means:
Systems must undergo appropriate security testing before release, including functional, security, and performance testing.

How to implement it:
Engineers should ensure every release passes SAST, DAST, dependency scanning, penetration testing (for major releases), and load testing. Acceptance environments should mirror production closely.

Real-world examples:

• Running OWASP ZAP as part of CI/CD.
• Using synthetic tests for API load validation.
• Conducting red-team style testing for critical systems.

---

📜 Logging & Monitoring Controls

---

A.8.12 – Logging

What this control means:
All relevant security, system, and application events must be logged, retained, and protected from tampering.

How to implement it:
Engineers should ensure cloud logs, IAM logs, EDR logs, API logs, and network logs all stream into a SIEM. Logs must be timestamped, access-controlled, and stored in immutable form if feasible. Logging coverage should be mapped against attack kill chains.

Real-world examples:

• CloudTrail logging all API calls.
• EDR logs ingested into SIEM with enrichment.
• Immutable log storage using S3 Object Lock.

---

A.8.13 – Monitoring Activities

What this control means:
Monitoring must actively detect anomalies, malicious activity, and policy violations.

How to implement it:
Engineers should write detection rules, integrate UEBA, enable alert correlation, and ensure MDR/SOC receives correct telemetry. Dashboards should track health, detection coverage, and response performance.

Real-world examples:

• Correlation rule detecting MFA fatigue attacks.
• UEBA spotting impossible travel anomalies.
• MDR generating investigations for high-severity alerts.

---

A.8.14 – Clock Synchronisation

What this control means:
All systems must use accurate and synchronised time sources, essential for correlation, forensics, and monitoring.

How to implement it:
Configure all systems to use approved NTP sources (internal or cloud). Validate time drift via monitoring tools. Ensure logs across platforms use consistent time zones or UTC.

Real-world examples:

• Cloud logs aligned to UTC across regions.
• NTP drift alerts in monitoring dashboards.
• SIEM requiring timestamp standardisation.

---

🔐 Cryptography & Key Management

---

A.8.15 – Use of Cryptography

What this control means:
Cryptographic controls must protect data in transit, at rest, and in use. Encryption standards must be documented and applied consistently.

How to implement it:
Enforce TLS 1.2+, encrypt cloud storage buckets, require HTTPS, manage keys properly, and ensure crypto libraries/frameworks are patched. Assess algorithms for obsolescence and remove weak ciphers.

Real-world examples:

• Enforcing HTTPS-only websites.
• Encrypting all cloud storage by default.
• Disabling outdated SSL/TLS ciphers.

---

A.8.16 – Key Management

What this control means:
Keys must be generated, stored, rotated, retired, and destroyed securely.

How to implement it:
Use managed key vaults (AWS KMS, Azure Key Vault), enforce strict access controls, rotate keys automatically, and prevent keys from being embedded in code or configs. Audit all key access through SIEM.

Real-world examples:

• KMS rotating keys every 90 days.
• Access logs showing which admin accessed which key.
• Secrets stored in Vault instead of Git repos.

---

📦 Source Code, Design & Service Security

---

A.8.17 – Access Control to Source Code

What this control means:
Access to source code must be controlled, monitored, and restricted to authorised developers.

How to implement it:
Use RBAC in Git systems, enforce branch protection, enable audit logs, disable anonymous access, and block direct pushes to protected branches. Source code for sensitive services should require MFA and limited membership groups.

Real-world examples:

• GitHub enforcing signed commits and branch protection.
• Limiting access to production IaC repos to senior engineers only.
• Audit logs sent from GitHub/GitLab to SIEM.

---

A.8.18 – Secure System Design

What this control means:
Systems must be designed according to secure architecture patterns and threat models.

How to implement it:
Engineers must use Zero Trust, least privilege, segmentation, secure API design, encryption, and secure network patterns by default. Formal threat modelling should occur before development begins.

Real-world examples:

• Using microsegmentation in cloud deployments.
• Designing APIs with OAuth2 and rate limiting.
• Using private endpoints instead of public URLs.

---

A.8.19 – Secure System Architecture (expanded control name)

What this control means:
Architectural decisions must follow security principles and be documented.

How to implement it:
Create architecture diagrams, define trust boundaries, document data flows, and embed security controls (WAF, IAM, DDoS protection). Architecture should be reviewed periodically for drift or obsolescence.

Real-world examples:

• Using WAF fronting all public APIs.
• Architecting autoscaling clusters with least privilege IAM roles.
• Adding API gateways with JWT validation.

---

🌐 Network Security Controls

---

A.8.20 – Network Security

What this control means:
Networks must be protected from unauthorised access, attacks, and lateral movement.

How to implement it:
Engineers must enforce segmentation, firewall rules, IDS/IPS, secure VPN (or ZTNA), network logging, secure DNS, and Zero Trust policies. Cloud network security groups must be locked down and regularly reviewed.

Real-world examples:

• Blocking east–west traffic between production and development networks.
• Using WireGuard or ZTNA instead of legacy VPNs.
• Firewall policies stored as IaC.

---

A.8.21 – Web Filtering

What this control means:
Web access must be controlled to prevent users from accessing harmful or unauthorised content.

How to implement it:
Deploy secure web gateways, DNS filtering, SSL inspection (where legally compliant), and policies blocking risky categories. Ensure filtering applies on-network and off-network via agents.

Real-world examples:

• Using Zscaler or Cisco Umbrella for all outbound traffic.
• Blocking malware domains at DNS layer.
• Alerting when users attempt to access risky categories.

---

☁️ Cloud-Specific Controls

---

A.8.23 – Cloud Services Security

What this control means:
Cloud services must be configured securely, monitored, and governed throughout their lifecycle.

How to implement it:
Enforce SSO/MFA, configure least privilege, enable full logging, encrypt storage, restrict admin APIs, and regularly run CSPM scans. Document the architecture of every cloud workload.

Real-world examples:

• Enabling CloudTrail across all AWS accounts.
• Azure Defender monitoring for risky IAM configurations.
• Blocking deployment to unapproved regions.

---

🗄 Backup & Redundancy

---

A.8.24 – Information Backup

What this control means:
Information must be backed up regularly, stored securely, encrypted, and tested for recoverability.

How to implement it:
Use automated backup schedules, encrypted offsite copies, immutable storage, and quarterly restoration tests. Protect backup consoles under MFA.

Real-world examples:

• Immutable S3 backup buckets.
• Daily VM snapshots plus weekly offsite copies.
• Quarterly DR test demonstrating restore times.

---

A.8.25 – Redundancy of Information Processing Facilities

What this control means:
Systems must include redundancy for critical elements to maintain availability.

How to implement it:
Engineers should deploy systems across AZs/regions, enable autoscaling, distribute workloads, and provide failover paths for DNS, databases, and network routes.

Real-world examples:

• Multi-AZ RDS deployments.
• Redundant VPN gateways.
• Load-balanced microservices.

---

🔧 Vulnerability, Hardening & Disposal

---

A.8.26 – Logging and Monitoring of Cloud Services

What this control means:
Cloud service activity must be monitored for anomalies and security issues.

How to implement it:
Enable cloud-native logging (CloudTrail, Azure Activity, GCP Audit Logs), ingest logs into SIEM, create detections for risky behaviours, and enforce retention. CSPM tools should monitor for misconfigurations continuously.

Real-world examples:

• Alerting on IAM role assumption from unusual IPs.
• Triggering detection on new public buckets.
• Monitoring for mass API failures.

---

A.8.27 – Technical Hardening

What this control means:
All systems must be hardened following best practices (CIS, NCSC, vendor baselines).

How to implement it:
Apply CIS baselines via MDM or config management, disable unnecessary services, restrict ports, enforce secure protocols, and test compliance regularly.

Real-world examples:

• CIS-L2 for critical servers.
• SSH configured for key-based authentication only.
• Removing legacy SSL ciphers.

---

A.8.28 – Vulnerability Scanning

What this control means:
Systems must be regularly scanned for vulnerabilities using automated tools.

How to implement it:
Schedule authenticated scans, integrate results into a remediation pipeline, enforce SLAs, and track historical trends.

Real-world examples:

• Nessus weekly authenticated scans.
• Container scanning for base image vulnerabilities.
• Scan results feeding into Jira tickets.

---

A.8.29 – Test Data

What this control means:
Test data must be protected from production leakage, and real production data should not be used in test environments unless adequately masked.

How to implement it:
Engineers must sanitise or mask datasets before using them outside production. Lower environments should restrict access, use mock data, and ensure encryption/logging is applied the same way as production. Automated pipelines should enforce masking before copying any database.

Real-world examples:

• Using synthetic PII for QA environments.
• Automated masking of customer data before exporting databases.
• Preventing analysts from cloning production databases without approval.

---

A.8.30 – Secure Disposal of Cloud Artefacts

What this control means:
Cloud artefacts such as snapshots, logs, images, containers, and temporary storage must be securely deleted to prevent data recovery.

How to implement it:
Engineers should enforce lifecycle policies, automate snapshot expiration, securely wipe or delete cloud storage blocks, and ensure retired workloads leave no residual data. Terraform/IaC should remove artefacts cleanly.

Real-world examples:

• Automatic S3 lifecycle rules deleting old logs.
• Securely deleting container layers or AMIs after use.
• Tearing down test environments with IaC, removing all residual disks.

📘 Senior Cyber Engineer ISO 27001:2022 Implementation Playbook

(Focused only on the controls that require engineering ownership)

This playbook is designed to guide a Senior Cyber Engineer through the practical implementation of the ISO 27001:2022 technical control set.
It is written as an operational document, not a policy.

---

🔵 1. Threat Intelligence & Asset Awareness

---

A.5.7 Threat Intelligence – Playbook Actions

Objective: Convert external threat intel into internal defences.

What to do:

• Subscribe to trusted TI feeds (open source + commercial).
• Feed indicators (IPs, hashes, CVEs, TTPs) into SIEM enrichment.
• Write new detection rules based on current threat actor behaviour.
• Review CVE trends weekly and convert relevant issues into patch tasks.
• Pivot intel against internal logs to find early compromise patterns.

Outputs:

• Updated SIEM rules
• SOC playbooks updated
• Patch and configuration recommendations

---

A.5.9 Inventory of Information & Assets – Playbook Actions

Objective: Ensure complete visibility of all assets.

What to do:

• Integrate EDR, CMDB, CSPM, and MDM to auto-populate inventories.
• Tag assets with owner, environment, classification, and criticality.
• Review inventory monthly for orphaned, unpatched, or unknown assets.
• Ensure all cloud services are registered and risk assessed.

Outputs:

• Up-to-date asset register
• Cloud resource inventory with classification tags

---

A.5.12 Classification of Information – Playbook Actions

Objective: Label and protect data based on sensitivity.

What to do:

• Apply classification tags to cloud storage, databases, SaaS tools.
• Configure DLP to respond to labels (block, warn, encrypt).
• Ensure automated labelling on documents containing PII/PCI/PHI.
• Enforce encryption on all classified datasets.

Outputs:

• Consistent labelling across services
• Automated DLP enforcement

---

🔵 2. Cloud Governance & Technical Configuration

---

A.5.18 Inventory of Cloud Services – Playbook Actions

Objective: Detect and control all cloud services used in the business.

What to do:

• Use CASB/CSPM to detect shadow SaaS.
• Maintain registry of every cloud application with owner + purpose.
• Ensure each cloud service is tied to SSO with MFA.
• Block unapproved high-risk cloud apps via DNS/web filtering.

Outputs:

• Cloud service directory
• Alerts for new/unknown cloud usage

---

A.5.23 Cloud Security – Playbook Actions

Objective: Apply secure configuration, monitoring, and logging.

What to do:

• Enable full audit logs (CloudTrail, Azure Activity).
• Enforce least-privilege IAM roles.
• Require encryption at rest and in transit.
• Run CSPM posture scans continuously.
• Implement IaC to remove manual configuration drift.

Outputs:

• CSPM reports
• Cloud IAM baseline
• Full log ingestion into SIEM

---

A.5.19 Configuration Management – Playbook Actions

Objective: Standardise secure configurations.

What to do:

• Define baseline configs (CIS, vendor benchmarks).
• Implement configuration using IaC/Ansible/MDM.
• Enable drift detection.
• Block or alert on unauthorised manual changes.

Outputs:

• Hardened baseline profiles
• Automated remediation pipelines

---

🔵 3. Identity & Access Security

---

A.8.2 Privileged Access Rights – Playbook Actions

Objective: Limit and control administrator access.

What to do:

• Use PAM for all admin actions.
• Enforce just-in-time access (e.g., Azure PIM).
• Require MFA + FIDO keys for all privileged accounts.
• Log all privileged activity.

Outputs:

• PAM audit logs
• Admin access workflow

---

A.8.4 Secure Authentication – Playbook Actions

Objective: Enforce strong, phishing-resistant authentication.

What to do:

• Add MFA everywhere.
• Block legacy auth (IMAP/POP/SMS/NTLM).
• Enforce conditional access.
• Deploy passwordless (FIDO2/WebAuthn) where possible.

Outputs:

• Conditional access policy set
• MFA compliance dashboard

---

A.8.3 Information Access Restrictions – Playbook Actions

Objective: Protect sensitive data through least privilege.

What to do:

• Implement strict RBAC across all cloud and on-prem services.
• Create pre-approved access bundles; no ad-hoc permissions.
• Use automated provisioning/deprovisioning.
• Enforce DLP and access logging.

Outputs:

• RBAC mapping
• Access request workflows

---

🔵 4. Endpoint, Malware & Vulnerability Management

---

A.8.1 User Endpoint Devices – Playbook Actions

Objective: Ensure endpoints remain secure and compliant.

What to do:

• Deploy EDR.
• Enforce disk encryption + firewall + secure baseline.
• Block untrusted USB devices.
• Ensure auto-patching for OS/apps.

Outputs:

• Endpoint compliance dashboard
• Device risk posture reports

---

A.8.6 Protection Against Malware – Playbook Actions

Objective: Prevent and detect malware, ransomware & exploits.

What to do:

• Ensure EDR coverage is 100%.
• Enable real-time scanning and behavioural detection.
• Deploy sandboxing for email/attachments.
• Block unsigned scripts and macros.

Outputs:

• EDR alert set
• Malware activity logs

---

A.8.7 Technical Vulnerability Management – Playbook Actions

Objective: Identify, prioritise, and remediate vulnerabilities.

What to do:

• Run authenticated scans weekly.
• Prioritise based on CVSS + exploitability.
• Patch within SLAs: Critical (7 days), High (14 days).
• Run container/image scanning for CI/CD.

Outputs:

• Vulnerability dashboard
• Patch compliance reports

---

🔵 5. Logging, Monitoring & Detection

---

A.8.12 Logging – Playbook Actions

Objective: Ensure full audit trails exist everywhere.

What to do:

• Enable logs on IAM, endpoints, cloud APIs, firewalls, SaaS tools.
• Stream all logs to SIEM.
• Protect logs from tampering (WORM/immutability).

Outputs:

• Log source inventory
• SIEM ingestion health checks

---

A.8.13 Monitoring Activities – Playbook Actions

Objective: Detect attacks and anomalous activity.

What to do:

• Write correlation rules (IAM + EDR + network).
• Integrate UEBA for behavioural analysis.
• Build SOAR workflows for auto-triage.
• Ensure MDR visibility across systems.

Outputs:

• Detection catalogue
• SOC/MDR investigation flow

---

A.8.14 Clock Synchronisation – Playbook Actions

Objective: Maintain forensic-ready logs.

What to do:

• Synchronise all systems to UTC NTP servers.
• Monitor timestamp drift.
• Validate time alignment in SIEM.

Outputs:

• NTP compliance report

---

🔵 6. Application Security & SDLC

---

A.8.9 Security in Development Processes – Playbook Actions

Objective: Embed security within development.

What to do:

• Add SAST, SCA, DAST, IaC scanning to all pipelines.
• Ensure code reviews cover security.
• Enforce secrets detection.
• Replace real PII with masked/synthetic data.

Outputs:

• Secure CI/CD pipeline
• SDLC security checklist

---

A.8.10 Secure Coding – Playbook Actions

Objective: Prevent known vulnerabilities through coding hygiene.

What to do:

• Train developers on secure coding principles.
• Use frameworks that enforce validation and encoding.
• Block insecure functions and patterns via linting.

Outputs:

• Secure coding standards
• Linter ruleset

---

A.8.11 Testing – Playbook Actions

Objective: Validate systems before release.

What to do:

• Conduct pre-release security testing (SAST/DAST/pen tests).
• Mirror prod as closely as possible in staging.
• Perform negative and abuse-case testing.

Outputs:

• Security test report
• Pen test remediation plan

---

🔵 7. Network, Cloud, Backup & Hardening

---

A.8.20 Network Security – Playbook Actions

Objective: Restrict, segment, and monitor the network.

What to do:

• Enforce segmentation, firewall rules, IDS/IPS.
• Block lateral movement.
• Use Zero Trust or ZTNA.
• Log DNS, firewall, and VPN events.

Outputs:

• Network zoning diagram
• Firewall-as-code repos

---

A.8.23 Cloud Service Security – Playbook Actions

Objective: Secure all cloud platforms.

What to do:

• Enable full audit logging.
• Restrict admin APIs.
• Harden IAM, storage, networking.
• Continuously run CSPM.

Outputs:

• Cloud security baseline
• Cloud misconfiguration dashboard

---

A.8.24 Information Backup – Playbook Actions

Objective: Ensure reliable, secure backups.

What to do:

• Automate backups.
• Use encrypted, immutable storage.
• Perform quarterly restore tests.
• Protect backup consoles with MFA.

Outputs:

• Backup schedule
• DR test results

---

A.8.27 Technical Hardening – Playbook Actions

Objective: Harden all systems.

What to do:

• Apply CIS/NCSC/STIG baselines.
• Disable insecure services and protocols.
• Use configuration scanning to enforce compliance.

Outputs:

• Hardening standard
• Compliance scan results

---

A.8.29 Test Data – Playbook Actions

Objective: Prevent production data leakage.

What to do:

• Mask or synthesise PII before use in dev/test.
• Restrict developer access to production datasets.
• Enforce DLP on test environments.

Outputs:

• Data masking scripts
• Test data governance checklist

---

📊 ISO 27001 Senior Cyber Engineer Summary Matrix

This matrix gives an at-a-glance reference for responsibilities and tooling.

---

Legend

🔧 = Implementation
🛡 = Protection
📊 = Monitoring
☁️ = Cloud
💻 = Endpoint/Infra
🔐 = IAM
🧪 = DevSecOps

---

Summary Matrix

ISO Control	Engineer Responsibilities	Practical Tooling
A.5.7 Threat Intelligence	Integrate TI feeds, build detections, enrich logs	MISP, OTX, VirusTotal, SIEM, SOAR
A.5.9 Asset Inventory	Auto-discovery, tagging, CMDB integration	EDR, CMDB, CSPM, MDM
A.5.12 Classification	Apply labels, enforce DLP, automate tagging	MIP/AIP, DLP, CASB
A.5.18 Cloud Inventory	Detect shadow IT, build SaaS registry	CASB, CSPM, DNS logs
A.5.19 Configuration Management	Harden systems, enforce IaC, detect drift	Terraform, Ansible, Intune, CIS-CAT
A.5.23 Cloud Security	Enable logging, secure IAM, encrypt, monitor	CloudTrail / Azure Activity / GCP Logs
A.5.30 Supply Chain Security	Validate vendor security, enable SSO, monitor	SSO, API gateways, vendor scanning
A.8.1 Endpoint Devices	EDR, encryption, patching, compliance	CrowdStrike, SentinelOne, Intune
A.8.2 Privileged Access	PAM, JIT access, MFA, logging	CyberArk, Azure PIM, Vault
A.8.3 Access Restrictions	RBAC, least privilege, revocation	IAM, RBAC tooling, DLP
A.8.4 Secure Authentication	MFA everywhere, conditional access	FIDO2, Azure AD/Okta
A.8.6 Malware Protection	EDR coverage, script blocking	EDR, SWG, sandboxing
A.8.7 Vulnerabilities	Scanning, patching, SLAs	Nessus, Qualys, container scanning
A.8.8 Config Management	Harden systems, enforce baselines	IaC, MDM, CIS tools
A.8.9 DevSecOps Development	SAST/SCA/DAST pipelines	GitLab/GitHub Security, Checkov
A.8.10 Secure Coding	Training, linting, code standards	SonarQube, ESLint, Bandit
A.8.11 Testing	Security tests before release	ZAP, Burp Suite, CI pipeline
A.8.12 Logging	Enable logging everywhere	SIEM, CSPM, log pipelines
A.8.13 Monitoring	Build detections, UEBA, SOAR	Sentinel, Splunk, Exabeam
A.8.14 Clock Sync	UTC time enforcement	NTP, Chrony
A.8.15 Cryptography	TLS, encryption, crypto standards	KMS, Cert-manager
A.8.16 Key Management	Key rotation, vault storage	HSM, Azure Key Vault, AWS KMS
A.8.17 Source Code Access	RBAC, branch protection	GitHub/GitLab
A.8.18 System Design	Secure design, trust boundaries	Architecture modelling tools
A.8.20 Network Security	Segmentation, firewalls, ZTNA	Palo Alto, Zero Trust, WireGuard
A.8.23 Cloud Monitoring	CSPM scanning, cloud logging	Wiz, Prisma, Defender
A.8.24 Backup	Backup, encryption, restore tests	Veeam, cloud snapshots
A.8.27 Hardening	CIS baselines, disable legacy protocols	Hardening scripts, MDM
A.8.29 Test Data	Masking, synthetic data, DLP	Data masking tools
A.8.30 Cloud Artefact Disposal	Delete snapshots, secure destruction	Lifecycle rules, IaC