{"id":79548,"date":"2026-10-28T06:32:50","date_gmt":"2026-10-28T06:32:50","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=79548"},"modified":"2026-10-28T06:32:51","modified_gmt":"2026-10-28T06:32:51","slug":"iso-iec-27001-explained-build-operate-and-audit-an-information-security-management-system","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/iso-iec-27001-explained-build-operate-and-audit-an-information-security-management-system\/","title":{"rendered":"ISO\/IEC 27001 Explained: Build, Operate, and Audit an Information Security Management System"},"content":{"rendered":"\n

A security program fails when it depends on individual heroes. A developer enables multifactor authentication, an administrator reviews logs, and a manager approves a policy, but nobody can answer a more important question: Are the right risks being managed consistently across the business?<\/strong> ISO\/IEC 27001 addresses that management problem.<\/p>\n\n\n\n

ISO\/IEC 27001 is a requirements standard for an Information Security Management System (ISMS). An ISMS is the coordinated combination of leadership, scope, risk assessment, security controls, evidence, measurement, and improvement that protects information. The published edition is ISO\/IEC 27001:2022, supplemented by Amendment 1:2024. ISO\/IEC 27002:2022 supplies implementation guidance for controls. ISO\/IEC 27001 certification is possible; there is no universal official ISO\/IEC 27001 maturity-level ladder<\/strong>.<\/p>\n\n\n\n

The business problem behind the standard<\/h2>\n\n\n\n

Consider a fictional company, Northstar Mobility, operating a cloud-based telemetry service. Its developers deploy APIs, its operations team manages AWS resources, its support team sees customer records, and several suppliers provide hosting and analytics. A single security product cannot answer whether access approvals are appropriate, cloud risks are understood, backups are recoverable, or vendors are reviewed. The ISMS connects those decisions to accountable owners and auditable evidence.<\/p>\n\n\n\n

The three classic protection objectives are confidentiality (information is disclosed only to authorized parties), integrity (information remains accurate and protected from unauthorized change), and availability (authorized users can access it when needed). The objective is risk management<\/strong>, not a claim that all risk has been eliminated.<\/p>\n\n\n\n

How the ISMS works<\/h2>\n\n\n\n
Business context and scopeIdentify assets and risksEvaluate and treat risksImplement controlsOperate and gather evidenceAudit and management reviewCorrect and improve<\/pre>\n\n\n\n
The auditable management-system requirements are organized in Clauses 4-10: context, leadership, planning, support, operation, performance evaluation, and improvement. Annex A is a reference control set used when checking risk treatment completeness. Its 93 controls are grouped into organizational, people, physical, and technological categories (37, 8, 14, and 34 respectively). They are not 93 universally mandatory implementations<\/strong>: the organization chooses necessary controls based on risk, obligations, and an applicability analysis, then justifies its decisions.<\/p>\n\n\n\n
Step 1: Define a defensible ISMS scope<\/h2>\n\n\n\n
Start with business services, locations, technologies, organizational units, interfaces, and dependencies. A sample scope statement is:<\/p>\n\n\n\n
\n
The ISMS covers design, development, operation, and customer support of the Northstar Mobility telemetry SaaS platform, including the employees, production cloud accounts, CI\/CD pipeline, relevant suppliers, and supporting corporate identity infrastructure.<\/p>\n<\/blockquote>\n\n\n\n
Map supporting systems that materially affect security, even if operated by a third party. Excluding a risky system to make an audit easier does not remove a real dependency. Identify interested parties: customers, regulators, personnel, suppliers, shareholders, and certification stakeholders. Record their relevant security requirements.<\/p>\n\n\n\n
Deliverable:<\/strong> approved scope statement and a boundary diagram listing included services and critical interfaces.<\/p>\n\n\n\n
Step 2: Establish ownership and policy<\/h2>\n\n\n\n
Appoint an executive sponsor, an ISMS owner, risk owners, control owners, and independent internal auditors. Publish an information security policy covering objectives, accountability, risk acceptance authority, employee obligations, escalation, and continuous improvement. A policy is meaningful only when teams know what behavior it requires.<\/p>\n\n\n\n
A practical responsibility model is:<\/p>\n\n\n\n
Decision or activity<\/th>Accountable owner<\/th>Evidence<\/th><\/tr><\/thead>
ISMS objectives and resources<\/td>Executive leadership<\/td>Approved goals and review minutes<\/td><\/tr>
Risk assessment method<\/td>Security leadership<\/td>Approved methodology<\/td><\/tr>
Application access<\/td>Application owner<\/td>Access review and approvals<\/td><\/tr>
Cloud vulnerability remediation<\/td>Platform engineering<\/td>Tickets, scan output, deployment records<\/td><\/tr>
Independent internal audit<\/td>Internal audit lead<\/td>Audit plan and findings<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Step 3: Inventory assets and assess risks<\/h2>\n\n\n\n
Identify information assets, their owners, locations, sensitivity, dependencies, and threats. Choose a consistent assessment methodology before scoring risks. For learning purposes, use likelihood and impact values of 1-5, where illustrative risk score = likelihood x impact<\/strong>. This numerical method is not prescribed by ISO\/IEC 27001.<\/p>\n\n\n\n
Risk ID<\/th>Scenario<\/th>Likelihood<\/th>Impact<\/th>Initial score<\/th>Treatment<\/th><\/tr><\/thead>
R-001<\/td>Privileged cloud account compromise<\/td>4<\/td>5<\/td>20<\/td>Reduce via phishing-resistant MFA and privileged-access review<\/td><\/tr>
R-002<\/td>Unrecoverable database after ransomware<\/td>3<\/td>5<\/td>15<\/td>Reduce via isolated backups and restore tests<\/td><\/tr>
R-003<\/td>Supplier processes telemetry beyond agreed purpose<\/td>2<\/td>4<\/td>8<\/td>Reduce via contractual and technical restrictions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Set risk acceptance criteria with the proper authority. Record residual risk after treatment; a control can reduce risk without removing it. A risk register should track treatment owner, due date, selected controls, evidence, remaining exposure, and acceptance decision.<\/p>\n\n\n\n
Step 4: Create the Statement of Applicability<\/h2>\n\n\n\n
The Statement of Applicability (SoA) is a central ISMS artifact. It records the controls determined necessary, explains why they are included, states whether they are implemented, and justifies exclusions from Annex A. Review the Annex A set to ensure no necessary control was overlooked; additional non-Annex-A controls can also be selected.<\/p>\n\n\n\n
Example (abbreviated and illustrative):<\/p>\n\n\n\n
Control reference<\/th>Applicability<\/th>Reason<\/th>Implementation evidence<\/th><\/tr><\/thead>
A.5.15 Access control<\/td>Included<\/td>Cloud and customer-data access risk<\/td>Identity policy, access review logs<\/td><\/tr>
A.5.23 Information security for use of cloud services<\/td>Included<\/td>Cloud-hosted workloads<\/td>Supplier review and cloud guardrails<\/td><\/tr>
A.8.8 Management of technical vulnerabilities<\/td>Included<\/td>Internet-facing services<\/td>Scan reports and remediation tickets<\/td><\/tr>
Physical control in a provider-operated facility<\/td>Assess, do not automatically exclude<\/td>Responsibilities may be shared<\/td>Provider assurance plus contractual allocation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The SoA is not a checkbox sheet. Its selection, justifications, implementation status, and links to actual evidence must be consistent with the risk treatment plan.<\/p>\n\n\n\n
Step 5: Implement and operate controls<\/h2>\n\n\n\n
Put security measures into normal work rather than making them occasional audit activities:<\/p>\n\n\n\n
    \n
  1. Identity: joiner\/mover\/leaver processes, least privilege, privileged-access approvals, MFA, service-account ownership.<\/li>\n\n\n\n
  2. Engineering: secure coding expectations, dependency checks, code reviews, release approvals, and secrets management.<\/li>\n\n\n\n
  3. Operations: asset inventory, configuration baselines, logging, vulnerability remediation, incident response, backups, and recovery testing.<\/li>\n\n\n\n
  4. People and suppliers: onboarding, training, contractual requirements, performance reviews, and offboarding.<\/li>\n\n\n\n
  5. Governance: document control, exceptions, risk acceptance, scheduled reviews, and performance reporting.<\/li>\n<\/ol>\n\n\n\n
    Typical evidence:<\/strong> approved policy versions, risk decisions, identity exports, infrastructure-as-code reviews, incident drills, backup restore logs, supplier due-diligence records, and change tickets. Secure sensitive evidence; audit artifacts can themselves reveal architectural weaknesses.<\/p>\n\n\n\n
    Hands-on lab: Build a small risk register<\/h2>\n\n\n\n
    Create a file named risk_review.py<\/code> on Windows, macOS, or Linux and paste the following Python 3 code. No extra packages are required.<\/p>\n\n\n
    import<\/span> csv\nfrom<\/span> pathlib import<\/span> Path\n\nrisks = [\n    {\"id\"<\/span>: \"R-001\"<\/span>, \"asset\"<\/span>: \"Cloud admin\"<\/span>, \"likelihood\"<\/span>: 4<\/span>, \"impact\"<\/span>: 5<\/span>, \"owner\"<\/span>: \"Platform\"<\/span>},\n    {\"id\"<\/span>: \"R-002\"<\/span>, \"asset\"<\/span>: \"Database backups\"<\/span>, \"likelihood\"<\/span>: 3<\/span>, \"impact\"<\/span>: 5<\/span>, \"owner\"<\/span>: \"SRE\"<\/span>},\n    {\"id\"<\/span>: \"R-003\"<\/span>, \"asset\"<\/span>: \"Vendor analytics\"<\/span>, \"likelihood\"<\/span>: 2<\/span>, \"impact\"<\/span>: 4<\/span>, \"owner\"<\/span>: \"Security\"<\/span>},\n]\n\nfor<\/span> risk in<\/span> risks:\n    risk[\"score\"<\/span>] = risk[\"likelihood\"<\/span>] * risk[\"impact\"<\/span>]\n    risk[\"priority\"<\/span>] = \"High\"<\/span> if<\/span> risk[\"score\"<\/span>] >= 15<\/span> else<\/span> \"Review\"<\/span>\n\nwith<\/span> Path(\"risk_register.csv\"<\/span>).open(\"w\"<\/span>, newline=\"\"<\/span>, encoding=\"utf-8\"<\/span>) as<\/span> f:\n    writer = csv.DictWriter(f, fieldnames=risks[0<\/span>].keys())\n    writer.writeheader()\n    writer.writerows(risks)\n\nfor<\/span> risk in<\/span> sorted(risks, key=lambda r: r[\"score\"<\/span>], reverse=True):\n    print(risk[\"id\"<\/span>], risk[\"asset\"<\/span>], risk[\"score\"<\/span>], risk[\"priority\"<\/span>])\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    Run python3 risk_review.py<\/code> on macOS\/Linux or py -3 risk_review.py<\/code> on Windows where the Python launcher is available. You should see R-001<\/code> first with score 20, then R-002<\/code> with score 15, and R-003<\/code> with score 8. Open risk_register.csv<\/code> and add treatment actions, evidence locations, and residual-risk decisions as an exercise.<\/p>\n\n\n\n
    Important:<\/strong> the thresholds, asset names, and risk ratings are training examples. A live ISMS must define its own criteria, document assumptions, and obtain appropriate approvals.<\/p>\n\n\n\n
    Step 6: Measure, audit, and improve<\/h2>\n\n\n\n
    Define performance indicators tied to security outcomes, for example:<\/p>\n\n\n\n
    Metric<\/th>Useful interpretation<\/th>Common failure<\/th><\/tr><\/thead>
    Critical vulnerability remediation time<\/td>How quickly exposure decreases<\/td>Counting only easy-to-fix findings<\/td><\/tr>
    Overdue access reviews<\/td>Unverified access entitlement risk<\/td>Measuring completions without checking quality<\/td><\/tr>
    Successful recovery exercises<\/td>Tested operational resilience<\/td>Treating backup success as proof of recoverability<\/td><\/tr>
    Supplier reviews completed<\/td>External dependency oversight<\/td>Ignoring the riskiest providers<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Plan an internal audit<\/strong> that checks both ISO requirements and your own processes, using auditors objective enough to assess the work. Record nonconformities, root causes, corrections, corrective actions, owners, and effectiveness checks. Management review should consider performance, risks, findings, changes, resource needs, and improvement opportunities.<\/p>\n\n\n\n
    For third-party certification, engage an appropriate accredited certification body, confirm scope and applicable edition, complete the document-focused Stage 1 and implementation-focused Stage 2 activities, address findings, and follow the body’s surveillance and recertification arrangements. An ISO certificate does not mean every attack is prevented; it attests to management-system conformity within its scope.<\/p>\n\n\n\n
    Common implementation mistakes<\/h2>\n\n\n\n