@open-agreements/open-agreements 0.2.0 → 0.2.2

package/skills/iso-27001-internal-audit/rules/change-management.md

@@ -0,0 +1,211 @@
+# Change Management Rules
+
+Per-control audit guidance for SDLC, configuration management, and change control.
+
+## A.8.25 — Secure Development Lifecycle
+
+**Tier**: Critical | **NIST**: SA-3, SA-8
+
+Establish rules for secure development of software and systems. Apply security requirements throughout the SDLC — design, development, testing, deployment, and maintenance.
+
+**Auditor hints**:
+- Auditors want to see SDLC DOCUMENTED, not just practiced informally
+- They'll check: threat modeling (even lightweight), secure coding guidelines, pre-deployment security checks
+- For startups: a documented PR review checklist that includes security considerations is sufficient
+- "We do code review" is not enough — show that security is part of the review criteria
+
+**Evidence collection**:
+```bash
+# GitHub: branch protection requires reviews
+gh api repos/{owner}/{repo}/branches/{branch}/protection | jq '{
+  required_pull_request_reviews: .required_pull_request_reviews.required_approving_review_count,
+  enforce_admins: .enforce_admins.enabled,
+  required_status_checks: .required_status_checks.contexts
+}'
+
+# GitHub: recent PRs showing review process
+gh pr list --state merged --limit 10 --json number,title,reviewDecision,mergedAt
+```
+
+---
+
+## A.8.26 — Application Security Requirements
+
+**Tier**: Relevant | **NIST**: SA-3
+
+Define and document security requirements for applications, including authentication, authorization, input validation, and data protection requirements.
+
+**Auditor hints**:
+- Auditors check if security requirements are captured BEFORE development, not added after
+- For web apps: OWASP Top 10 coverage is expected
+- API security requirements should address authentication, rate limiting, and input validation
+- If you use third-party libraries, security requirements should cover dependency management
+
+---
+
+## A.8.27 — Secure System Architecture and Engineering Principles
+
+**Tier**: Checkbox | **NIST**: SA-8
+
+Apply secure engineering principles to system architecture. Design systems with defense in depth, least privilege, and fail-secure defaults.
+
+**Auditor hints**:
+- Auditors look for architecture documentation that shows security considerations
+- Network segmentation (or VPC design) is the most common check
+- Zero trust principles are increasingly expected but not yet required
+- For cloud: show that environments are isolated (dev/staging/prod separation)
+
+---
+
+## A.8.28 — Secure Coding
+
+**Tier**: Relevant | **NIST**: SI-10, SI-11
+
+Apply secure coding practices to minimize vulnerabilities. Address input validation, output encoding, error handling, and cryptographic usage in code.
+
+**Auditor hints**:
+- Auditors may review a recent security-relevant code change to verify practices
+- SAST (static analysis) tool usage is strong evidence — even a free tool like Semgrep or CodeQL
+- Dependency scanning (Dependabot, Snyk) counts as part of secure coding
+- Error messages should not leak internal details (stack traces, SQL queries, file paths)
+
+**Evidence collection**:
+```bash
+# GitHub: code scanning alerts (CodeQL/SAST)
+gh api repos/{owner}/{repo}/code-scanning/alerts --paginate | jq 'length'
+
+# GitHub: Dependabot alerts
+gh api repos/{owner}/{repo}/dependabot/alerts?state=open | jq 'length'
+```
+
+---
+
+## A.8.29 — Security Testing in Development and Acceptance
+
+**Tier**: Checkbox | **NIST**: SA-11
+
+Define and implement security testing processes during development and before production deployment. This includes functional security testing, vulnerability scanning, and penetration testing.
+
+**Auditor hints**:
+- Annual penetration test is expected for SOC 2 and increasingly for ISO
+- For startups: automated security scanning in CI/CD is acceptable evidence between annual pentests
+- Acceptance testing should include security test cases, not just functional tests
+- Bug bounty programs count as continuous security testing
+
+---
+
+## A.8.30 — Outsourced Development
+
+**Tier**: Checkbox | **NIST**: SR-5
+
+When development is outsourced, define and enforce security requirements with the external party. Monitor compliance and ensure secure handover.
+
+**Auditor hints**:
+- If you use contractors for development, auditors check: NDAs, access provisioning/deprovisioning, code ownership
+- Contractor access should be time-limited and revoked at contract end
+- Code review requirements should apply equally to internal and external developers
+
+---
+
+## A.8.31 — Separation of Development, Test, and Production Environments
+
+**Tier**: Checkbox | **NIST**: SA-3
+
+Separate development, testing, and production environments to reduce the risk of unauthorized access or changes to production systems.
+
+**Auditor hints**:
+- Auditors check: can a developer push directly to production? Is prod data used in dev?
+- Environment separation means: different accounts/projects/subscriptions, not just different folders
+- Database access: dev should NOT have production database credentials
+- CI/CD pipeline should be the ONLY path to production
+
+**Evidence collection**:
+```bash
+# GCP: list projects (should show separate dev/staging/prod)
+gcloud projects list --format="json(projectId,name)"
+
+# Azure: list subscriptions
+az account list --output json | jq '.[].{name, id, state}'
+```
+
+---
+
+## A.8.32 — Change Management
+
+**Tier**: Critical | **NIST**: CM-3, SA-10
+
+Manage changes to information processing facilities and systems through a formal change management process. Changes should be requested, assessed, approved, implemented, and reviewed.
+
+**Auditor hints**:
+- Auditors want to see a CHANGE RECORD for every production change — git history is excellent evidence
+- They'll sample 5-10 recent changes and check: was there a request, review, approval, and implementation record?
+- Emergency changes ("hotfixes") must have retroactive review — skipping the process is acceptable if documented
+- Rollback capability should exist — auditors may ask "what happens if this change fails?"
+
+**Evidence collection**:
+```bash
+# GitHub: recent merged PRs (change records)
+gh pr list --state merged --limit 20 --json number,title,author,reviewDecision,mergedAt,mergedBy
+
+# GitHub: branch protection (prevents unreviewed changes)
+gh api repos/{owner}/{repo}/branches/main/protection | jq '{
+  required_reviews: .required_pull_request_reviews.required_approving_review_count,
+  dismiss_stale_reviews: .required_pull_request_reviews.dismiss_stale_reviews
+}'
+
+# GitHub: deployment history
+gh api repos/{owner}/{repo}/deployments --paginate | jq '.[0:10] | .[] | {environment, created_at, sha: .sha[0:8]}'
+```
+
+---
+
+## A.8.33 — Test Information
+
+**Tier**: Checkbox | **NIST**: SA-11
+
+Ensure test data is adequately protected, especially when production data is used for testing. Anonymize or mask production data before use in non-production environments.
+
+**Auditor hints**:
+- If you use production data for testing, it must be masked — this is where many startups fail
+- Synthetic test data is always preferred
+- Test databases should have the same access controls as the environment warrants
+- Automated tests should not contain hardcoded credentials or real PII
+
+---
+
+## A.8.34 — Protection of Information Systems During Audit Testing
+
+**Tier**: Checkbox | **NIST**: CA-2
+
+Protect production systems from disruption during audit testing. Audit activities (vulnerability scans, penetration tests) should be planned and authorized to minimize business impact.
+
+**Auditor hints**:
+- Auditors check that THEIR OWN testing is authorized and scoped — they'll ask you to sign off on the test plan
+- Penetration tests should have written authorization (Rules of Engagement document)
+- Vulnerability scans on production should be scheduled during low-traffic periods
+
+---
+
+## A.8.9 — Configuration Management
+
+**Tier**: Critical | **NIST**: CM-1, CM-2, CM-3, CM-4, CM-6, CM-7, SA-10, SI-7
+
+Define, document, and maintain secure configurations for hardware, software, and network components. Establish baselines and monitor for drift.
+
+**Auditor hints**:
+- Auditors want to see BASELINE CONFIGURATIONS — what is the "known good" state of your systems?
+- For cloud: Infrastructure as Code (Terraform, CloudFormation) IS your configuration baseline
+- Configuration drift detection is increasingly expected — even a weekly diff of IaC vs. deployed state
+- Container images should be built from documented base images with pinned versions
+
+**Evidence collection**:
+```bash
+# Terraform: show current state
+terraform state list | head -20
+
+# GCP: export compute instance configurations
+gcloud compute instances list --format=json | jq '.[] | {name, machineType, status}'
+
+# Docker: list base images
+docker image ls --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"
+```

package/skills/iso-27001-internal-audit/rules/encryption.md

@@ -0,0 +1,93 @@
+# Encryption Rules
+
+Per-control audit guidance for cryptographic controls.
+
+## A.8.24 — Use of Cryptography
+
+**Tier**: Critical | **NIST**: SC-8, SC-12, SC-13, SC-17, SC-28
+
+Define and implement rules for cryptographic controls including key management. Use cryptography to protect data confidentiality, integrity, and authenticity — both in transit and at rest.
+
+**Auditor hints**:
+- Auditors check TWO things: (1) is encryption enabled, (2) is key management documented
+- "Encryption at rest" must cover databases, backups, AND local storage (laptops)
+- "Encryption in transit" means TLS 1.2+ for all external connections — auditors will check with `openssl s_client`
+- Key rotation policy must exist even if rotation is automated — document the cadence
+- Deprecated algorithms are findings: MD5, SHA-1, DES, 3DES, RC4, TLS 1.0/1.1
+
+**Evidence collection**:
+```bash
+# Check TLS configuration on a domain
+openssl s_client -connect example.com:443 -tls1_2 < /dev/null 2>&1 | grep -E "Protocol|Cipher"
+
+# GCP: check encryption at rest (default is Google-managed keys)
+gcloud sql instances describe {instance} --format="json(settings.ipConfiguration,settings.dataDiskEncryptionConfiguration)"
+
+# Azure: check encryption at rest
+az storage account show --name {account} --query "encryption" --output json
+
+# GitHub: check for secrets in repos (Dependabot/secret scanning)
+gh api repos/{owner}/{repo}/secret-scanning/alerts --paginate | jq 'length'
+
+# macOS FileVault status
+fdesetup status
+```
+
+**Startup pitfalls**:
+- Using default cloud encryption (fine) but not documenting the key management approach
+- Storing API keys/secrets in code repositories — use vault/secrets manager
+- No certificate inventory — TLS certs expire and cause outages
+- Assuming HTTPS means all traffic is encrypted — internal service-to-service traffic may not use TLS
+
+---
+
+## A.8.10 — Information Deletion
+
+**Tier**: Relevant | **NIST**: SC-28
+
+Delete information when no longer needed, in accordance with the retention policy. Deletion should be verifiable and cover all copies (backups, replicas, caches).
+
+**Auditor hints**:
+- Auditors check the DATA RETENTION SCHEDULE and verify it's being followed
+- "We keep everything forever" is technically compliant but a GDPR risk if you handle PII
+- Backup retention is often overlooked — if backups contain deleted data, the deletion isn't complete
+- Soft-delete vs. hard-delete: auditors want to know which you use and whether soft-deleted data is eventually purged
+
+---
+
+## A.8.11 — Data Masking
+
+**Tier**: Relevant | **NIST**: SC-28
+
+Use data masking techniques to limit exposure of sensitive data, especially in non-production environments. Masking should maintain data utility while preventing unauthorized access to actual values.
+
+**Auditor hints**:
+- The main question: "Does your staging/dev environment use production data?"
+- If yes, is it masked/anonymized? If no, how do you generate test data?
+- Masking must be irreversible for non-production — tokenization is acceptable if the token store is access-controlled
+- Logs are a common masking gap — sensitive data in debug logs
+
+---
+
+## A.8.12 — Data Leakage Prevention
+
+**Tier**: Relevant | **NIST**: MP-7
+
+Apply measures to prevent unauthorized disclosure of information. Monitor for and block data exfiltration through email, web uploads, USB devices, and other channels.
+
+**Auditor hints**:
+- For startups, DLP usually means: email scanning for attachments with sensitive data, endpoint USB controls, and cloud storage access restrictions
+- Auditors won't expect enterprise DLP software from a startup, but they will ask: "What prevents an employee from emailing the customer database?"
+- GitHub is a DLP vector — check that repos are private by default and secret scanning is enabled
+
+**Evidence collection**:
+```bash
+# GitHub: verify private-by-default repo setting
+gh api orgs/{org} | jq '{default_repository_permission, members_can_create_public_repositories}'
+
+# GitHub: secret scanning alerts
+gh api orgs/{org}/secret-scanning/alerts --paginate | jq 'length'
+
+# macOS: check if USB storage is restricted
+profiles show -type configuration | grep -i "removable"
+```

package/skills/iso-27001-internal-audit/rules/incident-response.md

@@ -0,0 +1,127 @@
+# Incident Response Rules
+
+Per-control audit guidance for incident management lifecycle.
+
+## A.5.24 — Incident Management Planning and Preparation
+
+**Tier**: Critical | **NIST**: IR-1, IR-2, IR-3, IR-6, IR-8
+
+Define and maintain an incident response plan that covers roles, communication procedures, escalation paths, and post-incident review processes. The plan should be tested regularly.
+
+**Auditor hints**:
+- Auditors check three things: (1) plan exists, (2) plan has been tested, (3) people know the plan
+- A plan that hasn't been tested in > 12 months is a finding
+- "Tested" means tabletop exercise at minimum — a full simulation is ideal but not required for startups
+- The plan must include notification requirements (regulatory deadlines: GDPR 72 hours, etc.)
+- Contact lists must be current — auditors will spot-check phone numbers
+
+**Evidence collection**:
+- Incident response plan document (with version date)
+- Tabletop exercise records (date, participants, scenario, findings)
+- Communication tree / contact list (with last-verified date)
+- Training records showing IR training for relevant personnel
+
+---
+
+## A.5.25 — Assessment and Decision on Information Security Events
+
+**Tier**: Critical | **NIST**: IR-4, IR-5, IR-8
+
+Establish criteria for assessing whether security events are incidents, and define severity classification. Events should be triaged consistently using documented criteria.
+
+**Auditor hints**:
+- Auditors want to see a CLASSIFICATION SCHEME — not just "high/medium/low" but criteria for each level
+- They'll ask: "Show me an event that was NOT classified as an incident" to verify triage works both ways
+- The gap between "event" and "incident" is where findings hide — if everything is an incident, triage isn't working; if nothing is, detection isn't working
+
+**Evidence collection**:
+- Event classification criteria document
+- Sample of security events with triage decisions
+- Ticketing system export showing event-to-incident workflow
+
+```bash
+# GitHub security alerts (sample of events)
+gh api repos/{owner}/{repo}/security-advisories --paginate | jq '.[0:5]'
+
+# If using PagerDuty:
+# curl -H "Authorization: Token token={api_key}" https://api.pagerduty.com/incidents?limit=10
+```
+
+---
+
+## A.5.26 — Response to Information Security Incidents
+
+**Tier**: Critical | **NIST**: IR-4, IR-6, IR-8, IR-9
+
+Respond to incidents according to the documented plan. Contain the impact, preserve evidence, and communicate with stakeholders. Document all response actions.
+
+**Auditor hints**:
+- Auditors will review actual incident records, not just the plan
+- They look for: timeline of response actions, evidence of containment, stakeholder notifications
+- If there have been zero incidents in the audit period, they'll ask about NEAR-MISSES to verify the detection and response capability exists
+- Post-incident review (lessons learned) is required — just closing the ticket isn't enough
+
+**Evidence collection**:
+- Incident tickets with full timeline
+- Communication records (internal alerts, external notifications)
+- Containment actions documented
+- Post-incident review records
+
+---
+
+## A.5.27 — Learning from Information Security Incidents
+
+**Tier**: Checkbox | **NIST**: IR-9
+
+Use incident knowledge to strengthen controls, update procedures, and prevent recurrence. Feed lessons learned back into risk assessment and control improvements.
+
+**Auditor hints**:
+- This is about demonstrating a feedback loop — incident → root cause → corrective action → control update
+- Auditors check: "After your last incident, what changed?" If nothing changed, it's a finding
+- Maintain an incident register that tracks both the incident AND the resulting improvements
+
+---
+
+## A.5.28 — Collection of Evidence
+
+**Tier**: Checkbox | **NIST**: IR-4
+
+Establish procedures for collecting, preserving, and handling evidence related to security incidents, ensuring admissibility and chain of custody where legal proceedings may follow.
+
+**Auditor hints**:
+- Startups rarely need forensic-grade evidence preservation, but auditors check that logs aren't tampered with
+- Key question: "If you had a breach, could you reconstruct what happened?" If logs rotate too fast or aren't centralized, the answer is no
+- Immutable log storage (write-once) is best practice for audit trails
+
+---
+
+## A.5.29 — Information Security During Disruption
+
+**Tier**: Checkbox | **NIST**: IR-4
+
+Maintain information security controls during business disruptions. Security shouldn't be bypassed during incidents, outages, or DR scenarios.
+
+**Auditor hints**:
+- Classic failure: disabling MFA or firewall rules during an outage "to speed up recovery"
+- DR plans should explicitly state which security controls remain active during failover
+- If you have a "break glass" procedure (emergency admin access), it must be logged and reviewed
+
+---
+
+## A.6.8 — Information Security Event Reporting
+
+**Tier**: Relevant | **NIST**: IR-4, IR-6
+
+All personnel should know how to report security events. There should be a clear, accessible reporting channel and no negative consequences for good-faith reporting.
+
+**Auditor hints**:
+- Auditors ask random employees: "If you noticed suspicious activity, who would you report it to?"
+- The reporting channel must be EASY — a Slack channel, email alias, or phone number
+- Training records should show that employees have been told how to report events
+- No-retaliation policy should be documented
+
+**Evidence collection**:
+- Security event reporting procedure
+- Training records showing reporting awareness
+- Sample of reported events (even false positives demonstrate the system works)
+- Communication channel configuration (Slack channel, email alias)

package/skills/iso-27001-internal-audit/rules/isms-management.md

@@ -0,0 +1,164 @@
+# ISMS Management System Rules
+
+Per-clause audit guidance for ISO 27001:2022 Clauses 4-10.
+
+This is where most first-time audit failures happen. Startups focus on Annex A technical controls and neglect the management system clauses that auditors weight most heavily.
+
+## Clause 5 — Leadership and Commitment
+
+**Tier**: Critical | **NIST**: PM-1, PM-2
+
+Top management must demonstrate commitment to the ISMS by establishing policy, assigning roles, providing resources, and conducting management reviews. This is NOT delegatable to IT.
+
+**Auditor hints**:
+- Auditors look for EVIDENCE of management involvement, not just policy signatures
+- "Management review" must be a documented meeting with specific inputs/outputs defined in Clause 9.3
+- The information security policy must be SIGNED by top management (CEO/founder) and communicated to all personnel
+- ISMS scope must be approved by management — it can't be defined by IT alone
+- For startups: the founder IS top management — their engagement is visible and auditable
+
+**Evidence**:
+- Signed information security policy (with date)
+- Management review meeting minutes (at least annual)
+- ISMS scope document approved by management
+- Resource allocation evidence (budget, tools, personnel)
+
+**Startup pitfalls**:
+- Treating the security policy as a checkbox document that nobody reads
+- No management review conducted — or conducted but not documented
+- ISMS scope undefined or too vague ("everything we do")
+
+---
+
+## Clause 6 — Risk Assessment and Treatment
+
+**Tier**: Critical | **NIST**: PM-9, RA-3, RA-7
+
+Plan and conduct risk assessments to identify threats and vulnerabilities. Select risk treatment options (mitigate, accept, transfer, avoid) and implement controls from the Statement of Applicability.
+
+**Auditor hints**:
+- The risk assessment is the FOUNDATION of the ISMS — everything else flows from it
+- Auditors verify: risk assessment methodology is documented, risks are identified with likelihood and impact, treatment decisions are justified
+- The SoA must MATCH the risk assessment — every control in the SoA should trace back to a risk
+- Risk acceptance must be AUTHORIZED by management (documented approval)
+- Risk assessment must be CURRENT (within 12 months) and triggered by significant changes
+
+**Evidence**:
+- Risk assessment methodology document
+- Risk register (with likelihood, impact, risk level, treatment decision)
+- Statement of Applicability (SoA) with justification for inclusion/exclusion
+- Risk treatment plan showing implementation status
+- Risk acceptance records signed by management
+
+**Startup pitfalls**:
+- Copy-pasting a risk assessment template without tailoring to the actual business
+- SoA says "all controls applicable" without justification per control
+- Risk register never updated — last revision was pre-certification
+- No connection between risk assessment and control selection
+
+---
+
+## Clause 7 — Competence and Awareness
+
+**Tier**: Relevant | **NIST**: AT-1, AT-2, AT-3, AT-4
+
+Ensure personnel are competent for their security roles, aware of the security policy, and understand their contribution to the ISMS. Maintain training records.
+
+**Auditor hints**:
+- Auditors check competence for KEY ROLES: ISMS manager, incident responders, internal auditors, system administrators
+- Awareness training for ALL staff must be documented with completion dates
+- Competence means: education, training, experience, or certification — at least one should be documented per role
+- Internal auditors must demonstrate audit competence (training or certification) — can't just be "the IT person"
+
+**Evidence**:
+- Role descriptions with security competence requirements
+- Training records (completion dates, topics covered)
+- Security awareness program description
+- Internal auditor competence records (training, certification, or experience)
+
+---
+
+## Clause 8 — Operational Planning and Control
+
+**Tier**: Critical | **NIST**: CA-6, PM-10, RA-3, RA-7
+
+Execute the risk treatment plan. Implement planned controls, manage operational processes, and handle changes that affect the ISMS.
+
+**Auditor hints**:
+- This is the "do what you said you'd do" clause — auditors verify that planned actions from Clause 6 are actually implemented
+- Change management applies to the ISMS itself — changes to scope, policies, or controls should be documented
+- Outsourced processes within the ISMS scope must be controlled — if you outsource IT, you still own the risk
+
+**Evidence**:
+- Risk treatment plan with implementation status
+- Change records for ISMS changes
+- Outsourcing agreements with security controls (links to A.5.19-A.5.23)
+
+---
+
+## Clause 9 — Internal Audit and Management Review
+
+**Tier**: Critical | **NIST**: CA-2, PM-14
+
+Conduct internal audits at planned intervals to verify the ISMS conforms to requirements and is effectively implemented. Conduct management reviews to ensure continuing suitability and effectiveness.
+
+**Auditor hints**:
+- Internal audit is REQUIRED — "we'll do it next quarter" at certification time is a major nonconformity
+- Internal auditors must be INDEPENDENT — they can't audit their own work (Clause 9.2 requirement)
+- Management review has REQUIRED INPUTS (Clause 9.3.2): audit results, interested party feedback, risk assessment status, opportunities for improvement
+- Management review has REQUIRED OUTPUTS (Clause 9.3.3): decisions on improvement opportunities, resource needs, any changes to the ISMS
+- Auditors check that internal audit FINDINGS are TRACKED to closure
+
+**Evidence**:
+- Internal audit plan (annual schedule showing all ISMS areas)
+- Internal audit report(s) with findings
+- Evidence of auditor independence
+- Management review meeting minutes with all required inputs and outputs
+- Corrective action tracker showing internal audit findings through to closure
+
+**Startup pitfalls**:
+- Internal audit never done — this is a showstopper for certification
+- Internal audit done by the same person who manages the ISMS
+- Management review conducted but doesn't address all required inputs
+- Findings identified but no corrective actions implemented
+
+---
+
+## Clause 10 — Nonconformity and Continual Improvement
+
+**Tier**: Critical | **NIST**: CA-5, PM-4
+
+React to nonconformities, take corrective action, and continually improve the ISMS. Track nonconformities through root cause analysis, corrective action, and verification of effectiveness.
+
+**Auditor hints**:
+- Auditors look for a COMPLETE CYCLE: nonconformity identified → root cause analyzed → corrective action taken → effectiveness verified
+- Not every issue needs formal corrective action — observations and opportunities for improvement can be noted and tracked separately
+- "Continual improvement" means the ISMS should be demonstrably BETTER than last year — auditors compare year over year
+- If the same nonconformity recurs, the previous corrective action was ineffective — this is a major finding
+
+**Evidence**:
+- Nonconformity log/register
+- Corrective action records with root cause analysis
+- Evidence of effectiveness verification (follow-up check)
+- Improvement records (changes made to the ISMS based on lessons learned)
+
+---
+
+## Quick Reference: ISMS Document Checklist
+
+These documents are REQUIRED by ISO 27001:2022 — missing any is a nonconformity:
+
+| Document | Clause | Notes |
+|----------|--------|-------|
+| ISMS scope | 4.3 | Boundaries and applicability |
+| Information security policy | 5.2 | Signed by top management |
+| Risk assessment methodology | 6.1.2 | How risks are identified and evaluated |
+| Risk assessment results | 8.2 | Current risk register |
+| Statement of Applicability | 6.1.3 | All 93 controls: included/excluded with justification |
+| Risk treatment plan | 6.1.3 | How selected controls will be implemented |
+| Security objectives | 6.2 | Measurable security goals |
+| Competence evidence | 7.2 | Training records, qualifications |
+| Operational planning docs | 8.1 | Evidence of control implementation |
+| Internal audit results | 9.2 | Audit report(s) with findings |
+| Management review results | 9.3 | Meeting minutes with required inputs/outputs |
+| Nonconformity records | 10.1 | Corrective action log |