{"id":79544,"date":"2026-10-28T06:31:55","date_gmt":"2026-10-28T06:31:55","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=79544"},"modified":"2026-10-28T06:31:57","modified_gmt":"2026-10-28T06:31:57","slug":"cybersecurity-and-information-security-complete-tutorial-collection","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/cybersecurity-and-information-security-complete-tutorial-collection\/","title":{"rendered":"Cybersecurity and Information Security – Complete Tutorial Collection"},"content":{"rendered":"\n

Nine standalone end-to-end guides plus a cross-framework implementation path.<\/p>\n\n\n\n

Cybersecurity and Information Security: Nine Practical Standards Tutorials<\/h1>\n\n\n\n

A complete learning path from security fundamentals to audit-ready implementation<\/h2>\n\n\n\n

A business can face security risks in a cloud service, a payment checkout, a factory automation system, a connected vehicle, a government contract, and an AI assistant. These systems share many underlying security principles, but they do not share a single universal compliance standard or maturity score<\/strong>.<\/p>\n\n\n\n

This series explains nine major frameworks and standards, with standalone educational articles, practical example architectures, evidence expectations, runnable offline Python labs, and knowledge checks. The examples use Northstar Mobility<\/strong>, a fictional company operating SaaS telemetry, industrial-connected systems, embedded components, defense engineering work, payments, and AI services. All lab data are synthetic.<\/p>\n\n\n\n

Choose the framework that matches the problem<\/h2>\n\n\n\n
Framework<\/th>Best starting question<\/th>Main result<\/th>Avoid confusing with<\/th><\/tr><\/thead>
ISO\/IEC 27001<\/td>How do we run information security as a managed business system?<\/td>ISMS and possible certification<\/td>A mandated 1-5 maturity rating<\/td><\/tr>
NIST CSF<\/td>Where do we stand against desired security outcomes?<\/td>Current\/target profiles, prioritized improvement<\/td>A universal compliance checklist<\/td><\/tr>
NIST SP 800-53<\/td>What controls should we choose and how can they be tested?<\/td>Selected controls, documented assessments<\/td>A one-size-fits-all federal baseline<\/td><\/tr>
SOC 2<\/td>How can service customers receive independent assurance?<\/td>CPA attestation report, Type I\/II<\/td>ISO-style certification<\/td><\/tr>
PCI DSS<\/td>How do we protect payment data and validate applicable controls?<\/td>Applicable PCI DSS validation artifacts<\/td>Merchant validation levels as security maturity<\/td><\/tr>
IEC 62443<\/td>How do we protect industrial control operations safely?<\/td>OT security design and evidence<\/td>A universal enterprise SL4 grade<\/td><\/tr>
ISO\/SAE 21434<\/td>How do we engineer cybersecurity across the vehicle lifecycle?<\/td>Automotive TARA, goals, requirements, verification<\/td>Automotive SPICE capability levels<\/td><\/tr>
CMMC<\/td>What must defense suppliers safeguard and assess under contracts?<\/td>Required level and assessment\/affirmation evidence<\/td>A static rollout calendar<\/td><\/tr>
ISO\/IEC 42001<\/td>How do we govern the risks and impacts of AI use?<\/td>AIMS and possible certification<\/td>A promise of flawless AI outputs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The learning sequence<\/h2>\n\n\n\n

Foundation:<\/strong> Start with ISO\/IEC 27001<\/a> for scope, governance, risk, controls, and audit thinking. Follow with NIST CSF<\/a> for a current-to-target security improvement program.<\/p>\n\n\n\n

Control engineering and assurance:<\/strong> Use NIST SP 800-53<\/a> to learn control implementation and assessment, then SOC 2<\/a> to learn evidence over time and independent attestation.<\/p>\n\n\n\n

Specialized environments:<\/strong> Learn payment security in PCI DSS<\/a>, OT\/industrial segmentation and security levels in IEC 62443<\/a>, and vehicle engineering in ISO\/SAE 21434<\/a>.<\/p>\n\n\n\n

Regulated contracting and emerging governance:<\/strong> Understand contract-driven defense safeguards in CMMC<\/a> and organization-wide AI governance in ISO\/IEC 42001<\/a>.<\/p>\n\n\n\n

The universal implementation workflow<\/h2>\n\n\n\n
Identify business service and applicable obligationsDefine system boundary and data flowsDetermine risks, threats, and impactsSelect required controls and ownersImplement in policies, engineering, and operationsCollect reliable operating evidenceAssess and report resultsRemediate and reassess<\/pre>\n\n\n\n
This workflow is an educational synthesis, not a substitute for the prescribed lifecycle of each standard. Formal applicability, clause interpretation, assessment scope, certification routes, and reporting depend on the exact standard, contract, regulator, and independent assessor where relevant.<\/p>\n\n\n\n
One security capability can contribute to multiple frameworks<\/h2>\n\n\n\n
For example, an access-review workflow can produce reusable operational artifacts:<\/p>\n\n\n\n
Shared capability<\/th>How different programs may use the evidence<\/th><\/tr><\/thead>
Asset and service inventory<\/td>ISMS risk assessment, CSF Identify, SP 800-53 control boundary, SOC 2 system description, CMMC scoping<\/td><\/tr>
Privileged identity controls<\/td>ISO\/IEC 27001 risk treatment, NIST SP 800-53 AC\/IA, SOC 2 access criteria, PCI DSS access requirements<\/td><\/tr>
Change approval and testing<\/td>ISO\/IEC 27001 operations, SOC 2 change criteria, SP 800-53 configuration management, ISO\/SAE 21434 development evidence<\/td><\/tr>
Supplier oversight<\/td>ISO\/IEC 27001 supplier risk, NIST CSF Govern, SOC 2 subservice organizations, PCI DSS third parties, CMMC covered subcontractors<\/td><\/tr>
Vulnerability response<\/td>NIST SP 800-53 flaw remediation, PCI DSS vulnerability management, IEC 62443 OT-safe lifecycle, ISO\/SAE 21434 post-production monitoring<\/td><\/tr>
Risk\/impact assessment<\/td>ISO\/IEC 27001 ISMS risk process, NIST CSF profiles, IEC 62443 zones, ISO\/SAE 21434 TARA, ISO\/IEC 42001 AI impact assessments<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
But evidence reuse is not automatic control equivalence.<\/strong> The same screenshot may be useful in multiple contexts, yet each requirement can have distinct scope, test objectives, wording, cadence, and reviewer expectations. Maintain a crosswalk with source clauses and accountable review.<\/p>\n\n\n\n
Build a common evidence directory<\/h2>\n\n\n\n
A structure for a training or internal working project:<\/p>\n\n\n
security-program\/\n  01-governance\/\n    scope.md\n    policy.md\n    roles-and-approvals.md\n  02-architecture\/\n    services.md\n    data-flows.md\n    third-party-dependencies.md\n  03-risk\/\n    methodology.md\n    risk-register.md\n    threat-models.md\n  04-controls\/\n    control-inventory.md\n    control-owners.md\n    exceptions.md\n  05-evidence\/\n    access-reviews\/\n    changes\/\n    backups-and-restores\/\n    detection-and-incidents\/\n    supplier-assessments\/\n  06-assurance\/\n    internal-audits\/\n    assessment-findings\/\n    corrective-actions\/\n    management-reviews\/\n<\/code><\/span><\/pre>\n\n\n
Protect this repository. Do not store secrets, raw payment-card details, controlled defense information, restricted automotive designs, or real customer data in example folders or public Git repositories. Use access controls and retain evidence according to contracts and applicable requirements.<\/p>\n\n\n\n
A reusable control-traceability template<\/h2>\n\n\n\n
Field<\/th>Example entry<\/th><\/tr><\/thead>
Requirement source<\/td>Chosen standard and exact clause\/control ID<\/td><\/tr>
Scope<\/td>Service, environment, data type, organization<\/td><\/tr>
Risk or objective<\/td>Privileged account compromise<\/td><\/tr>
Control owner<\/td>Identity platform team<\/td><\/tr>
Design description<\/td>Federated identity and privileged access review<\/td><\/tr>
Implementation location<\/td>Identity provider and administrative workflows<\/td><\/tr>
Test<\/td>Verify approved grants and access removal<\/td><\/tr>
Evidence<\/td>Sampled approvals, account exports, test record<\/td><\/tr>
Result<\/td>Implemented \/ finding \/ not applicable with justification<\/td><\/tr>
Remediation<\/td>Named owner, due date, verification<\/td><\/tr>
Review cadence<\/td>As determined by risk and applicable requirements<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The template deliberately avoids invented official maturity scores. Programs may require precise statuses, methods, and artifacts; use the authoritative standard or assessor guidance for formal reporting.<\/p>\n\n\n\n
A 12-week learning and implementation exercise<\/h2>\n\n\n\n
This schedule is an example for a learning lab, not a claim that certification or regulatory compliance can be completed in 12 weeks.<\/p>\n\n\n\n
Weeks<\/th>Focus<\/th>Expected outputs<\/th><\/tr><\/thead>
1-2<\/td>Business context, obligations, service scope, data flow<\/td>Scope statement and architecture<\/td><\/tr>
3-4<\/td>Assets, scenarios, risk and impact assessments<\/td>Risk register and first threat models<\/td><\/tr>
5-6<\/td>Current\/target outcomes and controls<\/td>Gap profile, control owners, implementation backlog<\/td><\/tr>
7-8<\/td>Practical safeguards and evidence design<\/td>Identity, logging, backup, change and supplier evidence samples<\/td><\/tr>
9-10<\/td>Engineering-domain exercises<\/td>OT zone model, OTA threat model, payment scope, AI impact analysis<\/td><\/tr>
11<\/td>Authorized test and internal review<\/td>Findings, missing evidence, control retests<\/td><\/tr>
12<\/td>Leadership review and future plan<\/td>Risk decisions, corrective actions, next review plan<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Capstone exercise: A connected mobility company<\/h2>\n\n\n\n
Imagine Northstar Mobility launches a vehicle diagnostic service that collects telemetry, accepts online customer payments, uses AI to summarize support cases, and contracts with a defense prime for one unrelated engineering project.<\/p>\n\n\n\n
Assignment 1: Define separate scopes.<\/strong> The SaaS security management system may be broader than the SOC 2 report boundary. The PCI DSS boundary is defined by payment data flows and security-impacting components. The automotive security boundary includes vehicle E\/E items and interfaces. The defense assessment boundary follows applicable contracts and FCI\/CUI handling. The AI management scope includes defined AI uses and governance. Never pretend these five are automatically identical.<\/p>\n\n\n\n
Assignment 2: Identify intersecting risks.<\/strong> Cloud identity compromise can affect SaaS operations, customer data, and payment-related administration. OTA release-signing compromise can affect vehicle cybersecurity. Poorly controlled AI retrieval can expose sensitive data. Unapproved data sharing may create defense contract concerns.<\/p>\n\n\n\n
Assignment 3: Produce reusable evidence without overclaiming.<\/strong> Create one control inventory with multiple standard mappings. For each mapping, record exact applicability, test objective, evidence source, and responsible reviewer. One control may produce evidence supporting several obligations, but the determination of conformity remains specific to each program.<\/p>\n\n\n\n
Assignment 4: Lead an incident tabletop.<\/strong> A release credential is suspected compromised on the same day a suspicious support AI response is reported. Ask which teams decide containment, how product and customer consequences are separated, when automotive and AI impact assessments must be revisited, what regulatory or contractual reporting clocks might apply, and what records are preserved. Use the actual contract and law before deciding notification obligations.<\/p>\n\n\n\n
Assignment 5: Present to leadership.<\/strong> Explain the top five risks, existing safeguards, evidence quality, residual decisions, supplier dependencies, and a prioritized improvement roadmap. Use plain business language and do not assert compliance or certification before it has been established.<\/p>\n\n\n\n
Final exam: Nine questions<\/h2>\n\n\n\n
    \n
  1. What is the difference between an ISO\/IEC 27001 SoA and a generic control checklist?<\/li>\n\n\n\n
  2. Why are NIST CSF Tiers not per-control maturity scores?<\/li>\n\n\n\n
  3. How do SP 800-53, 53A, and 53B differ?<\/li>\n\n\n\n
  4. Why does SOC 2 Type II require evidence across a reporting period?<\/li>\n\n\n\n
  5. Why does outsourcing payments reduce, but not automatically eliminate, PCI DSS obligations?<\/li>\n\n\n\n
  6. How do target, capability, and achieved IEC 62443 security levels differ?<\/li>\n\n\n\n
  7. Why is ISO\/SAE 21434 TARA not interchangeable with ISO 26262 HARA?<\/li>\n\n\n\n
  8. Why does suspending CMMC Phase II not cancel contract safeguards?<\/li>\n\n\n\n
  9. What AI-specific risks and impacts does ISO\/IEC 42001 require an organization to govern beyond general information security?<\/li>\n<\/ol>\n\n\n\n
    Answers:<\/strong> (1) The SoA records selected controls, implementation status, reasons for inclusion, and justifications for exclusions against the applicable risk treatment process. (2) Tiers characterize rigor of cybersecurity risk governance\/management practices. (3) Catalog, assessment procedures, and baselines. (4) Because operation over time must be assessed, not just point-in-time design. (5) Provider, site-integrity, third-party, and validation responsibilities can remain. (6) Risk target, designed capability, and real achieved protection. (7) Their risk objectives and methods address different sources of harm. (8) The underlying requirements still attach through applicable obligations. (9) Model\/data lifecycle, impact on affected parties, oversight, reliability, misuse, transparency, and ongoing evaluation.<\/p>\n\n\n\n
    Current reference baseline<\/h2>\n\n\n\n
    The articles use official publications and program guidance checked on October 28, 2026<\/strong>. Important state-sensitive references: ISO\/IEC 27001:2022 plus Amendment 1:2024; NIST CSF 2.0; NIST SP 800-53 Rev. 5 with Release 5.2.0 updates; PCI DSS v4.0.1; ISO\/SAE 21434:2021 with a later edition under development; CMMC Phase II suspension announced July 13, 2026; ISO\/IEC 42001:2023. The standalone articles link to authoritative sources for detailed verification.<\/p>\n\n\n\n
    For publishing in WordPress:<\/strong> Standard Markdown code fences work in Markdown-aware editors. Mermaid diagrams require a supported plugin or renderer; this package also includes a wordpress_plain\/<\/code> directory with diagrams replaced by descriptive text, allowing clean pasting without Mermaid support. Import one standalone article per WordPress post. Official citations are ordinary links rather than hidden writer instructions.<\/p>\n\n\n\n
    Copyright and scope:<\/strong> ISO, IEC, AICPA, PCI SSC, and other official standards may be licensed or copyrighted. These tutorials paraphrase publicly described structures and add original examples. For certification, regulatory claims, formal assessment, or legal interpretation, use the authoritative licensed material, contract and program rules, and qualified assessors.<\/p>\n\n\n\n
    \n\n\n\n
    ISO\/IEC 27001 Explained: Build, Operate, and Audit an Information Security Management System<\/h1>\n\n\n\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