open-agreements 0.2.0 → 0.2.2

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 |

package/skills/iso-27001-internal-audit/rules/logging-monitoring.md

@@ -0,0 +1,96 @@
+# Logging and Monitoring Rules
+
+Per-control audit guidance for audit trails, log management, and security monitoring.
+
+## A.8.15 — Logging
+
+**Tier**: Critical | **NIST**: AU-1, AU-2, AU-3, AU-4, AU-5, AU-6, AU-9, AU-11, AU-12, SI-4
+
+Produce, store, and protect logs that record activities, exceptions, faults, and security-relevant events. Logs should be centralized, tamper-evident, and retained for an adequate period.
+
+**Auditor hints**:
+- Auditors check FIVE things: (1) what is logged, (2) where logs go, (3) how long retained, (4) who can access/modify, (5) are they reviewed
+- "We use CloudWatch/Stackdriver" is only half the answer — auditors want to know WHAT events trigger alerts
+- Minimum logging: authentication events (success + failure), privilege escalation, data access, configuration changes, admin actions
+- Log retention: 12 months minimum for ISO, 1 year for SOC 2 (some regulated industries: 7 years)
+- Tamper protection: logs should be write-once or stored in a separate account with restricted access
+
+**Evidence collection**:
+```bash
+# GCP: check audit logging configuration
+gcloud projects get-iam-policy {project} --format=json | jq '.auditConfigs'
+
+# GCP: list log sinks (centralization)
+gcloud logging sinks list --format=json
+
+# Azure: check diagnostic settings
+az monitor diagnostic-settings list --resource {resource_id} --output json
+
+# GitHub: audit log (org)
+gh api orgs/{org}/audit-log?per_page=5 | jq '.[0:3]'
+
+# AWS: CloudTrail status
+# aws cloudtrail describe-trails --output json
+# aws cloudtrail get-trail-status --name {trail_name}
+```
+
+**Startup pitfalls**:
+- Logging enabled but never reviewed — logs without monitoring are just storage costs
+- Log retention too short — default cloud retention is often 30-90 days, auditors want 12 months
+- No centralization — logs scattered across services with no single pane of glass
+- Sensitive data in logs — PII, passwords, tokens appearing in debug logs
+
+---
+
+## A.8.16 — Monitoring Activities
+
+**Tier**: Critical | **NIST**: AU-6, CA-7, SI-4
+
+Monitor networks, systems, and applications for anomalous behavior. Define what "anomalous" means for your environment and configure alerts accordingly.
+
+**Auditor hints**:
+- Auditors distinguish between LOGGING (passive) and MONITORING (active) — you need both
+- They'll ask: "Show me your alert configuration" and "When was the last alert triggered?"
+- If zero alerts have fired in the audit period, either monitoring is too loose or the environment is unusually quiet — auditors will probe which
+- Monitoring should cover: failed authentication (brute force), privilege escalation, unusual data access patterns, configuration changes
+- Response to alerts must be documented — "we saw the alert and investigated" needs a ticket or log entry
+
+**Evidence collection**:
+```bash
+# GCP: alerting policies
+gcloud monitoring policies list --format=json | jq '.[].displayName'
+
+# Azure: alert rules
+az monitor alert list --output json | jq '.[].{name, enabled, severity}'
+
+# PagerDuty / Opsgenie: recent incidents
+# curl -H "Authorization: Token token={key}" https://api.pagerduty.com/incidents?limit=5
+```
+
+---
+
+## A.8.17 — Clock Synchronization
+
+**Tier**: Relevant | **NIST**: AU-8
+
+Synchronize clocks of all information processing systems to an approved time source. Consistent timestamps across systems are essential for incident investigation and evidence correlation.
+
+**Auditor hints**:
+- Cloud services handle this automatically (NTP synced) — auditors mainly check that you haven't overridden it
+- On-premises servers or VMs need explicit NTP configuration
+- Timestamps in logs should use UTC and ISO 8601 format for consistency
+- If evidence timestamps from different systems don't align, auditors will question the integrity
+
+**Evidence collection**:
+```bash
+# macOS: NTP status
+sntp -d time.apple.com 2>&1 | head -5
+
+# Linux: NTP sync status
+timedatectl status | grep -E "NTP|synchronized"
+
+# Docker containers: clock is synced with host (usually fine)
+
+# GCP: instance time sync (automatic for Compute Engine)
+# Azure: VM time sync (automatic for Azure VMs)
+```

package/skills/iso-27001-internal-audit/rules/people-controls.md

@@ -0,0 +1,161 @@
+# People Controls Rules
+
+Per-control audit guidance for HR security lifecycle.
+
+## A.6.1 — Screening
+
+**Tier**: Critical | **NIST**: PS-1, PS-2, PS-3
+
+Conduct background verification checks on all candidates before employment, proportionate to the role's access to sensitive information. Re-screen at defined intervals for high-risk roles.
+
+**Auditor hints**:
+- Auditors sample employee files to verify background checks were completed BEFORE start date
+- For startups: at minimum, verify identity and right to work; criminal background checks for roles with data access
+- Contractor/vendor screening is often missed — if they access your systems, they need screening too
+- Re-screening is recommended but not always required — document your policy either way
+- International hires need jurisdiction-appropriate screening
+
+**Evidence collection**:
+- HR records showing background check completion dates vs. start dates
+- Background check provider contract/agreement
+- Screening policy document defining scope per role type
+
+---
+
+## A.6.2 — Terms and Conditions of Employment
+
+**Tier**: Critical | **NIST**: PS-6
+
+Employment agreements should include information security responsibilities, including confidentiality obligations, acceptable use, and consequences for non-compliance. These apply during and after employment.
+
+**Auditor hints**:
+- Auditors check that EVERY employee has a signed agreement with security clauses — even founders
+- The agreement must cover: confidentiality, IP assignment, acceptable use, and post-termination obligations
+- Contractors need equivalent agreements (often separate NDAs)
+- Auditors sample 3-5 employee files to verify signatures exist
+
+**Evidence collection**:
+- Template employment agreement (showing security clauses)
+- Sample of signed agreements (redacted as needed)
+- Contractor NDA/security agreement template
+
+---
+
+## A.6.3 — Information Security Awareness, Education, and Training
+
+**Tier**: Relevant | **NIST**: AT-1, AT-2
+
+Ensure all personnel receive appropriate security awareness training at onboarding and regular intervals. Training should cover the organization's security policies, incident reporting, and role-specific threats.
+
+**Auditor hints**:
+- Auditors want COMPLETION RECORDS, not just "we have a training program"
+- Annual refresher training is the minimum expected cadence
+- Phishing simulation results count as evidence of awareness training effectiveness
+- Role-specific training (developers get secure coding, admins get privilege management) earns extra credit
+- New hire training should happen within first 30 days — auditors check dates
+
+**Evidence collection**:
+- Training completion records (export from LMS or training platform)
+- Training content outline/syllabus
+- Phishing simulation results (if applicable)
+- New hire onboarding checklist showing training step
+
+---
+
+## A.6.4 — Disciplinary Process
+
+**Tier**: Relevant | **NIST**: PS-8
+
+Establish a formal disciplinary process for personnel who commit security policy violations. The process should be communicated to all employees and applied consistently.
+
+**Auditor hints**:
+- Auditors check that a policy EXISTS and is communicated — they won't ask for examples of disciplinary actions
+- The policy should be referenced in the employee handbook or security policy
+- It should cover: escalation levels, investigation process, possible sanctions
+- For startups: having this documented in the employee handbook is sufficient
+
+---
+
+## A.6.5 — Responsibilities After Termination or Change of Employment
+
+**Tier**: Critical | **NIST**: PS-4, PS-5
+
+Define and enforce information security responsibilities that remain valid after employment ends or changes. Promptly revoke access when employment terminates.
+
+**Auditor hints**:
+- This is the #1 people control that fails — auditors cross-reference termination dates with access revocation dates
+- "48-hour rule": access should be revoked within 24-48 hours of termination, ideally same-day
+- Role changes should trigger access review — people accumulate permissions over time
+- Departing employees should return all company equipment and confirm data deletion from personal devices
+- Exit interviews should include security reminders (ongoing confidentiality obligations)
+
+**Evidence collection**:
+```bash
+# Cross-reference: get list of terminated users, check against active accounts
+# Google Workspace: suspended users (should correlate with terminations)
+gam print users fields primaryEmail,suspended,suspensionReason | grep "True"
+
+# GitHub: check for org members who should have been removed
+gh api orgs/{org}/members --paginate | jq '.[].login'
+
+# Compare against HR termination list (manual step)
+```
+
+---
+
+## A.6.6 — Confidentiality or Non-Disclosure Agreements
+
+**Tier**: Relevant | **NIST**: PS-6
+
+Identify and document confidentiality requirements, and ensure agreements are signed by personnel and external parties who access organizational information.
+
+**Auditor hints**:
+- Auditors verify that NDAs/confidentiality agreements cover: employees, contractors, vendors, and any third party with system access
+- The agreement should define: what's confidential, duration of obligation, consequences of breach
+- For startups: confidentiality clause in the employment agreement + separate NDA for contractors
+- Auditors sample files to verify signatures — electronic signatures are acceptable
+
+---
+
+## A.6.7 — Remote Working
+
+**Tier**: Relevant | **NIST**: AC-17, PE-17
+
+Define security requirements for remote working, including endpoint protection, network security, physical security of work environment, and data handling.
+
+**Auditor hints**:
+- With remote-first startups, this control is increasingly important
+- Auditors check: VPN/zero-trust access, endpoint encryption, screen lock policy, acceptable use for home networks
+- Physical security of home office is hard to verify — document the policy and self-attestation
+- Wi-Fi security: employees should not work on public networks without VPN
+
+**Evidence collection**:
+```bash
+# macOS: verify FileVault encryption
+fdesetup status
+
+# macOS: verify screen lock
+system_profiler SPConfigurationProfileDataType | grep -A5 "maxInactivity"
+
+# MDM: endpoint compliance status (depends on your MDM tool)
+```
+
+---
+
+## A.6.8 — Information Security Event Reporting
+
+**Tier**: Relevant | **NIST**: IR-4, IR-6
+
+All personnel should know how to identify and report security events through defined channels. The organization should make reporting easy and ensure no negative consequences for good-faith reporting.
+
+**Auditor hints**:
+- Auditors will ask random employees: "How would you report a security incident?"
+- The answer should be consistent (same channel/process) — if it varies, training is inadequate
+- False positive reports are GOOD — they show the system is working and people are vigilant
+- No-retaliation policy should be explicit in the security policy
+
+**Evidence collection**:
+- Incident reporting procedure document
+- Training records confirming reporting awareness
+- Reporting channel configuration (Slack channel, email alias, ticketing system)
+- Sample of reported events (even false positives)

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

@@ -0,0 +1,92 @@
+# Supplier Management Rules
+
+Per-control audit guidance for third-party and supply chain risk.
+
+## A.5.19 — Information Security in Supplier Relationships
+
+**Tier**: Relevant | **NIST**: AC-20, SA-4, SA-9, SR-1, SR-3
+
+Define and implement processes to manage security risks associated with supplier relationships. Establish security requirements in supplier agreements and monitor compliance.
+
+**Auditor hints**:
+- Auditors want a VENDOR INVENTORY — a list of all suppliers who access your data or systems
+- Each vendor should have: a contract with security clauses, a risk assessment, and periodic review
+- SOC 2 Type II reports from vendors are the gold standard evidence — request annually
+- For SaaS tools: the vendor's security page or trust center is a starting point, but not sufficient alone
+
+**Evidence collection**:
+- Vendor inventory/register with risk classification
+- Vendor security agreements or contract clauses
+- SOC 2 / ISO 27001 reports from critical vendors
+- Vendor risk assessment records
+
+---
+
+## A.5.20 — Addressing Information Security Within Supplier Agreements
+
+**Tier**: Relevant | **NIST**: PS-7, SR-3, SR-8
+
+Include information security requirements in agreements with suppliers and service providers. Agreements should address access controls, incident notification, audit rights, and data handling.
+
+**Auditor hints**:
+- Auditors sample 3-5 vendor contracts to verify security clauses exist
+- Key clauses to check: data protection, incident notification timeline, right to audit, sub-processor controls
+- For cloud providers: Data Processing Agreements (DPAs) should be in place if handling PII
+- "We use their standard terms" — auditors want to see you REVIEWED those terms for security adequacy
+
+---
+
+## A.5.21 — Managing Information Security in the ICT Supply Chain
+
+**Tier**: Relevant | **NIST**: AC-20, SA-4, SA-9, SR-2, SR-3
+
+Address information security risks in the ICT supply chain. Assess risks from third-party components, open-source dependencies, and outsourced development.
+
+**Auditor hints**:
+- For startups: this is primarily about dependency management — what open-source libraries do you use and how do you track vulnerabilities?
+- Auditors check: dependency scanning tool (Dependabot, Snyk), process for responding to critical CVEs
+- Software Bill of Materials (SBOM) is increasingly expected but not yet universally required
+- Container image provenance — know where your base images come from
+
+**Evidence collection**:
+```bash
+# GitHub: Dependabot alerts
+gh api repos/{owner}/{repo}/dependabot/alerts?state=open | jq 'length'
+
+# GitHub: Dependabot configuration
+gh api repos/{owner}/{repo}/contents/.github/dependabot.yml 2>/dev/null | jq '.content' -r | base64 -d
+
+# npm: audit
+# npm audit --json
+
+# Python: pip-audit
+# pip-audit --format=json
+```
+
+---
+
+## A.5.22 — Monitoring, Review, and Change Management of Supplier Services
+
+**Tier**: Relevant | **NIST**: AC-20, SA-9, SR-2, SR-5, SR-6
+
+Regularly monitor, review, and manage changes to supplier services. Track supplier security posture and assess impact of supplier-side changes.
+
+**Auditor hints**:
+- Auditors want to see PERIODIC REVIEW of vendor security — not just at onboarding
+- Annual review of critical vendor SOC 2 reports is the minimum expectation
+- Track vendor security incidents — sign up for vendor status pages and security advisories
+- Change management: when a vendor changes their service (new features, infrastructure migration), assess security impact
+
+---
+
+## A.5.23 — Information Security for Use of Cloud Services
+
+**Tier**: Checkbox | **NIST**: SA-9
+
+Define and manage information security requirements for cloud service usage. Establish processes for cloud service acquisition, operation, monitoring, and exit.
+
+**Auditor hints**:
+- Auditors check that you have a CLOUD SECURITY POLICY or that cloud usage is addressed in your general security policy
+- For cloud-native startups: demonstrate that you've reviewed your cloud provider's shared responsibility model
+- Data residency and jurisdictional requirements should be documented (where is data stored?)
+- Cloud exit strategy: what happens if you need to migrate away? Is data exportable?

package/skills/nda/SKILL.md

@@ -151,3 +151,12 @@ Use `list_templates` (MCP) or `list --json` (CLI) for the latest inventory and f
 - All templates produce Word DOCX files preserving original formatting
 - Templates are licensed by their respective authors (CC-BY-4.0 or CC0-1.0)
 - This tool does not provide legal advice — consult an attorney
+
+## Bespoke edits (beyond template fields)
+
+If you need to edit boilerplate or add custom language that is not exposed as a template field,
+use the `edit-docx-agreement` skill to surgically edit the generated DOCX and produce a
+tracked-changes output for review. This requires a separately configured Safe Docx MCP server.
+
+Note: templates licensed under CC-BY-ND-4.0 (e.g., YC SAFEs) can be filled for your own use
+but must not be redistributed in modified form.

package/skills/open-agreements/SKILL.md

@@ -180,3 +180,12 @@ Templates are discovered dynamically — always use `list_templates` (MCP) or `l
 - Templates are licensed by their respective authors (CC-BY-4.0, CC0-1.0, or CC-BY-ND-4.0)
 - External templates (CC-BY-ND-4.0, e.g. YC SAFEs) can be filled for your own use but must not be redistributed in modified form
 - This tool does not provide legal advice — consult an attorney
+
+## Bespoke edits (beyond template fields)
+
+If you need to edit boilerplate or add custom language that is not exposed as a template field,
+use the `edit-docx-agreement` skill to surgically edit the generated DOCX and produce a
+tracked-changes output for review. This requires a separately configured Safe Docx MCP server.
+
+Note: templates licensed under CC-BY-ND-4.0 (e.g., YC SAFEs) can be filled for your own use
+but must not be redistributed in modified form.