@open-agreements/open-agreements 0.2.2 → 0.3.0

package/skills/soc2-readiness/rules/risk-assessment.md

@@ -0,0 +1,100 @@
+# Risk Assessment — CC 3.1–3.4
+
+Per-criterion audit guidance for risk objectives, identification, fraud risk, and change impact analysis.
+
+## CC 3.1 — Risk objectives
+
+**Priority**: High | **NIST**: PM-9, RA-1 | **ISO**: C.6.1.1
+
+Auditors verify that the organization defines clear objectives against which risks are assessed. Without stated objectives, there's no basis for evaluating whether risks are acceptable. In practice, this means the organization has documented what it's trying to protect, what "good" looks like, and what level of risk is tolerable.
+
+**What auditors test**:
+- Information security objectives are documented and approved by management
+- Objectives are specific enough to be measurable (e.g., "99.9% uptime" not just "high availability")
+- Objectives align with business strategy and customer commitments (SLAs, contracts)
+- Risk appetite or tolerance statement exists — management has decided how much risk is acceptable
+- Objectives are reviewed at least annually and updated when business changes
+
+**Evidence to prepare**:
+- Information security policy with stated objectives (effective date within audit period)
+- Risk appetite statement or risk tolerance matrix (signed by management)
+- SLA commitments to customers that drive security objectives
+- Management review minutes where objectives were discussed/approved
+- Year-over-year comparison showing objectives were reviewed and updated
+
+**Startup pitfalls**:
+- No written security objectives — "don't get hacked" is not a measurable objective
+- Objectives copied from a template without customization to actual business context
+- Risk appetite never discussed — every risk is treated equally instead of being prioritized
+
+---
+
+## CC 3.2 — Risk identification and analysis
+
+**Priority**: High | **NIST**: RA-3 | **ISO**: C.6.1.2, C.8.2
+
+Auditors verify that the organization systematically identifies and analyzes risks to achieving its objectives. The risk assessment must be documented, cover relevant categories (operational, technical, compliance, people), and use a consistent methodology for evaluating likelihood and impact.
+
+**What auditors test**:
+- Formal risk assessment conducted at least annually with documented methodology
+- Risk register includes: risk description, likelihood, impact, risk rating, owner, and treatment decision
+- Risk categories cover: technical (infra, code), operational (process, people), compliance (regulatory), and third-party
+- Risk assessment considers both internal and external threats
+- Assessment methodology is consistent (e.g., 5×5 likelihood-impact matrix used uniformly)
+
+**Evidence to prepare**:
+- Risk register (spreadsheet or GRC tool export) with all required fields populated
+- Risk assessment methodology document (how risks are scored and prioritized)
+- Most recent risk assessment report with date and participants
+- Threat landscape analysis or threat modeling documentation
+- Risk register change log showing risks added, updated, or closed during audit period
+
+**Startup pitfalls**:
+- Risk register is a checkbox exercise — created once, never updated
+- Only technical risks listed — operational, compliance, and people risks are absent
+- Risk assessment done by one person in isolation — should involve cross-functional input
+- All risks rated "medium" to avoid triggering remediation
+
+---
+
+## CC 3.3 — Fraud risk
+
+**Priority**: Medium | **NIST**: RA-3 | **ISO**: C.6.1.2
+
+Auditors verify that the organization considers the potential for fraud when assessing risks — both internal (employee misuse, embezzlement, data theft) and external (social engineering, account takeover). This doesn't require a massive fraud program; it requires that fraud scenarios are part of the risk assessment.
+
+**What auditors test**:
+- Risk assessment explicitly includes fraud risk scenarios (not just technical vulnerabilities)
+- Internal fraud risks considered: data theft by insiders, financial fraud, unauthorized access abuse
+- External fraud risks considered: phishing, business email compromise, social engineering
+- Segregation of duties addresses fraud opportunity (e.g., person approving payments ≠ person initiating)
+- Management override controls: even founders/executives cannot bypass financial or access controls without detection
+
+**Evidence to prepare**:
+- Risk register entries specifically categorized as fraud risks
+- Segregation of duties matrix for financial and access management processes
+- Anti-fraud controls documentation (approval workflows, dual authorization for payments)
+- Phishing simulation results demonstrating awareness of social engineering threats
+- Financial reconciliation procedures showing detection controls for unauthorized transactions
+
+---
+
+## CC 3.4 — Change impact on controls
+
+**Priority**: Medium | **NIST**: RA-3, CM-4 | **ISO**: C.6.1.2, A.8.9
+
+Auditors verify that the organization assesses how changes — business, technical, regulatory, or personnel — affect the internal control environment. When the company adds a new product, enters a new market, adopts a new cloud provider, or undergoes significant personnel changes, the risk assessment should be revisited.
+
+**What auditors test**:
+- Process exists for evaluating control impact when significant changes occur
+- Evidence of risk reassessment triggered by actual changes during the audit period
+- New systems, vendors, or services underwent security review before deployment
+- Organizational changes (mergers, rapid hiring, leadership changes) triggered control reviews
+- Regulatory changes relevant to the business were identified and controls adjusted
+
+**Evidence to prepare**:
+- Change impact assessment records for significant changes during the audit period
+- Security review documentation for new vendors, systems, or services onboarded
+- Risk register entries added or modified in response to business changes
+- Management review minutes discussing impact of organizational changes on controls
+- Regulatory monitoring log showing awareness of relevant regulatory developments

package/skills/soc2-readiness/rules/system-operations.md

@@ -0,0 +1,170 @@
+# System Operations — CC 7.1–7.5
+
+Per-criterion audit guidance for configuration management, monitoring, incident response, and recovery.
+
+## CC 7.1 — Configuration and baseline monitoring
+
+**Priority**: Critical | **NIST**: CM-6, RA-5 | **ISO**: A.8.9, A.8.8
+
+Auditors verify that production systems run from documented, approved configurations and that drift from baselines is detected. This means infrastructure-as-code, golden images, or documented configuration standards — not ad-hoc server setup.
+
+**What auditors test**:
+- Configuration baselines exist for production systems (OS hardening, application settings, network rules)
+- Drift detection: mechanism to identify when running config diverges from approved baseline
+- Configuration changes follow the change management process (CC 8.1)
+- Default credentials and unnecessary services are removed from production systems
+- Firewall rules and security group configurations are reviewed at least quarterly
+
+**Evidence to prepare**:
+```bash
+# GCP: firewall rules
+gcloud compute firewall-rules list --format=json | jq '.[] | {name, direction, allowed, sourceRanges, targetTags}'
+
+# GCP: instance configurations
+gcloud compute instances list --format=json | jq '.[] | {name, machineType, zone, status}'
+
+# Azure: NSG rules
+az network nsg list --output json | jq '.[] | {name, location, securityRules: [.securityRules[] | {name, access, direction, sourceAddressPrefix, destinationPortRange}]}'
+
+# GitHub: infrastructure-as-code repos (Terraform, Pulumi, etc.)
+gh repo list {org} --json name,description --jq '.[] | select(.name | test("infra|terraform|pulumi|deploy"))'
+```
+- Infrastructure-as-code repository with version history
+- CIS benchmark assessment results (if available)
+- Configuration review records from most recent quarterly review
+
+**Startup pitfalls**:
+- Production servers configured manually via SSH — no reproducible baseline exists
+- Security groups with 0.0.0.0/0 inbound rules left from early development
+- No documentation of what "production configuration" actually is
+
+---
+
+## CC 7.2 — Anomaly detection and monitoring
+
+**Priority**: Critical | **NIST**: AU-6, SI-4 | **ISO**: A.8.15, A.8.16
+
+Auditors assess whether the organization collects, centralizes, and actively monitors logs for security-relevant events. Passive log collection is insufficient — there must be alerting rules that trigger investigation when anomalies occur.
+
+**What auditors test**:
+- Log centralization: security events from all systems flow to a single platform (SIEM or log aggregator)
+- Alert rules configured for: authentication failures, privilege escalation, unauthorized access attempts, configuration changes
+- Sample 2-3 recent alerts: verify each was investigated and documented with a resolution
+- Log retention covers the full audit period (typically 12 months for Type II)
+- Log integrity: logs are protected from tampering (write-once storage or separate account)
+
+**Evidence to prepare**:
+```bash
+# GCP: alerting policies
+gcloud monitoring policies list --format=json | jq '.[].displayName'
+
+# GCP: log sinks (centralization)
+gcloud logging sinks list --format=json | jq '.[] | {name, destination, filter}'
+
+# GCP: log retention settings
+gcloud logging buckets list --location=global --format=json | jq '.[] | {name, retentionDays}'
+
+# Azure: alert rules
+az monitor metrics alert list --output json | jq '.[] | {name, enabled, severity}'
+
+# Azure: diagnostic settings (log forwarding)
+az monitor diagnostic-settings list --resource {resource_id} --output json
+```
+- SIEM dashboard screenshot showing active alert rules
+- Sample alert investigation records (ticket or incident log)
+- Log retention policy document
+
+**Startup pitfalls**:
+- Logs exist in cloud provider but nobody monitors them — no alert rules configured
+- Alert fatigue: hundreds of alerts firing daily, all ignored
+- Log retention set to default 30 days — insufficient for a 12-month audit period
+
+---
+
+## CC 7.3 — Incident response
+
+**Priority**: Critical | **NIST**: IR-4 | **ISO**: A.5.24, A.5.25
+
+Auditors verify that the organization has a defined, tested process for responding to security incidents. The plan must exist before the audit period — writing it during the audit is a finding. Expect auditors to walk through a recent incident or tabletop exercise.
+
+**What auditors test**:
+- Incident response plan exists, is approved by management, and was in effect during the audit period
+- Plan covers: identification, containment, eradication, recovery, and lessons learned
+- Roles and responsibilities are defined (who leads response, who communicates, who escalates)
+- Plan has been tested: tabletop exercise or response to actual incident within the audit period
+- Post-incident reviews are conducted and documented with action items
+
+**Evidence to prepare**:
+- Incident response plan document (with version date proving it predates the audit period)
+- Tabletop exercise records: scenario, participants, decisions made, findings
+- Post-incident review reports (if real incidents occurred)
+- On-call rotation or escalation contact list
+- Incident severity classification matrix
+
+**Startup pitfalls**:
+- No written plan — "we'd just figure it out" is a guaranteed finding
+- Plan exists but has never been tested — auditors expect at least one tabletop exercise per year
+- No post-incident review process — incidents happen but lessons aren't captured
+- Incident response plan written by one person and unknown to the rest of the team
+
+---
+
+## CC 7.4 — Incident communication
+
+**Priority**: High | **NIST**: IR-5, IR-6 | **ISO**: A.5.25, A.5.26
+
+Beyond responding to incidents internally, auditors check whether the organization communicates appropriately with affected parties — customers, regulators, and management. Notification timelines and channels should be predefined, not improvised.
+
+**What auditors test**:
+- Communication plan: who gets notified, through what channel, within what timeframe
+- Customer notification SLAs match contractual commitments (check customer agreements for breach notification terms)
+- Regulatory notification requirements identified by jurisdiction (e.g., 72 hours for GDPR, state breach laws)
+- Management receives periodic incident summaries (at least quarterly)
+- Status page or customer communication channel for service-affecting incidents
+
+**Evidence to prepare**:
+- Incident communication procedures (section of IR plan or standalone document)
+- Sample customer notification (if a reportable incident occurred during audit period)
+- Regulatory notification requirements matrix (jurisdiction × data type × timeline)
+- Management incident summary reports
+- Status page URL and historical incident postings
+
+---
+
+## CC 7.5 — Recovery operations
+
+**Priority**: Critical | **NIST**: CP-4, CP-9, CP-10 | **ISO**: A.5.30, A.8.13
+
+Auditors verify that the organization can recover from incidents and disasters — not just that backups exist, but that recovery has been tested and meets defined objectives. Untested backups are assumed to be non-functional.
+
+**What auditors test**:
+- Backup configuration: automated, encrypted, and stored separately from production (different region or account)
+- Backup frequency matches RPO (recovery point objective) — if RPO is 1 hour, daily backups fail
+- Restore testing: at least one successful restore test during the audit period, documented with results
+- RTO/RPO defined for critical systems and achievable based on test results
+- Disaster recovery plan covering major failure scenarios (region outage, data corruption, ransomware)
+
+**Evidence to prepare**:
+```bash
+# GCP: Cloud SQL backup configuration
+gcloud sql instances describe {instance} --format=json | jq '{backupConfiguration, settings: {backupConfiguration}}'
+
+# GCP: recent backups
+gcloud sql backups list --instance={instance} --limit=10 --format=json | jq '.[0:5] | .[] | {id, startTime, status, type}'
+
+# Azure: backup status
+az backup item list --resource-group {rg} --vault-name {vault} --output json | jq '.[] | {name, properties: {lastBackupTime, protectionState}}'
+
+# GCP: snapshot policies
+gcloud compute resource-policies list --format=json | jq '.[] | {name, snapshotSchedulePolicy}'
+```
+- Backup restore test report (date, scope, time to restore, success/failure, issues encountered)
+- RTO/RPO definitions per critical system
+- Disaster recovery plan document
+- Business impact analysis identifying critical systems and acceptable downtime
+
+**Startup pitfalls**:
+- Cloud provider "handles backups" — but automated backups may not be enabled or may not cover all services
+- Backups exist but have never been restored — first restore attempt during a real outage reveals corruption
+- No defined RTO/RPO — "as fast as possible" is not measurable
+- DR plan is a copy-paste template that doesn't match actual infrastructure

package/skills/soc2-readiness/rules/trust-services.md

@@ -1,230 +0,0 @@
-# Trust Services Criteria — Detailed Guidance
-
-Per-criterion guidance for SOC 2 audits. Covers all 5 trust service categories.
-
-## Security (Common Criteria) — Always Required
-
-### CC 6.1 — Logical Access Security
-
-**Priority**: Critical | **NIST**: AC-2, AC-3, IA-2, SC-28 | **ISO**: A.5.15, A.8.5, A.8.24
-
-The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
-
-**What auditors test**:
-- Sample user accounts: verify access is appropriate for role
-- Check MFA enforcement on all systems with sensitive data
-- Verify encryption at rest and in transit
-- Test that unauthorized access attempts are blocked and logged
-
-**Evidence to prepare**:
-```bash
-# User access list with roles
-gam print users fields primaryEmail,name,orgUnitPath,isAdmin,isEnforcedIn2Sv
-
-# GitHub: org access settings
-gh api orgs/{org} | jq '{two_factor_requirement_enabled, default_repository_permission}'
-
-# Encryption: TLS check
-openssl s_client -connect {host}:443 -tls1_2 < /dev/null 2>&1 | grep "Protocol"
-```
-
----
-
-### CC 6.2 — Access Provisioning and Deprovisioning
-
-**Priority**: Critical | **NIST**: AC-2, PS-4, PS-5 | **ISO**: A.5.18, A.6.5
-
-New access requests require authorization. Access is removed promptly when no longer needed.
-
-**What auditors test**:
-- Sample 5-10 new hires: verify access was authorized before provisioning
-- Sample 5-10 terminations: verify access was revoked within 24-48 hours
-- Check for orphaned accounts (active accounts with no corresponding employee)
-
-**Evidence to prepare**:
-- HR-to-IT onboarding workflow documentation
-- Termination checklist with IT steps
-- Cross-reference: termination dates vs. last-active dates in systems
-
----
-
-### CC 7.2 — Anomaly Detection and Monitoring
-
-**Priority**: Critical | **NIST**: AU-6, SI-4 | **ISO**: A.8.15, A.8.16
-
-The entity monitors system components and anomalies that indicate malicious acts, natural disasters, and errors.
-
-**What auditors test**:
-- Alert configuration: what triggers alerts?
-- Sample alerts: show a recent alert and the response
-- Log retention: are logs kept for the full audit period?
-- Log centralization: is there a single view of security events?
-
-**Evidence to prepare**:
-```bash
-# GCP: alerting policies
-gcloud monitoring policies list --format=json | jq '.[].displayName'
-
-# GCP: log sinks
-gcloud logging sinks list --format=json
-
-# Azure: alert rules
-az monitor alert list --output json | jq '.[].{name, enabled}'
-```
-
----
-
-### CC 7.5 — Recovery Operations
-
-**Priority**: Critical | **NIST**: CP-4, CP-9, CP-10 | **ISO**: A.5.30, A.8.13
-
-The entity identifies, develops, and implements activities to recover from identified security incidents.
-
-**What auditors test**:
-- Backup configuration: are backups automated and encrypted?
-- Backup testing: has a restore been tested in the audit period?
-- DR plan: does it exist and has it been tested?
-- RTO/RPO: are they defined and achievable?
-
-**Evidence to prepare**:
-```bash
-# GCP: backup configuration
-gcloud sql backups list --instance={instance} --format=json | jq '.[0:5]'
-
-# Backup restore test documentation (manual)
-```
-
----
-
-### CC 8.1 — Change Management
-
-**Priority**: Critical | **NIST**: CM-3, CM-5, SA-3 | **ISO**: A.8.9, A.8.25, A.8.32
-
-Changes to infrastructure, data, software, and procedures are authorized, designed, developed, configured, documented, tested, approved, and implemented.
-
-**What auditors test**:
-- Sample 10-15 production changes: verify each had authorization, testing, and approval
-- Emergency change process: how are hotfixes handled?
-- Segregation: developers can't push directly to production
-- Rollback: can changes be reverted?
-
-**Evidence to prepare**:
-```bash
-# GitHub: merged PRs with review status
-gh pr list --state merged --limit 20 --json number,title,author,reviewDecision,mergedAt,mergedBy
-
-# GitHub: branch protection
-gh api repos/{owner}/{repo}/branches/main/protection | jq '{
-  required_reviews: .required_pull_request_reviews.required_approving_review_count,
-  enforce_admins: .enforce_admins.enabled
-}'
-```
-
----
-
-## Availability — For SaaS and Infrastructure
-
-### A 1.1 — System Availability Monitoring
-
-**Priority**: High | **NIST**: SC-5, SI-4 | **ISO**: A.8.6, A.8.16
-
-Monitor capacity and availability to meet commitments.
-
-**What auditors test**:
-- Uptime monitoring: is there a system monitoring availability?
-- Capacity planning: is there a process for scaling?
-- Status page: is availability communicated to customers?
-
----
-
-### A 1.2 — Recovery Planning
-
-**Priority**: High | **NIST**: CP-2, CP-6, CP-7 | **ISO**: A.5.30, A.8.14
-
-Environmental protections and recovery infrastructure support availability commitments.
-
-**What auditors test**:
-- Multi-AZ or multi-region deployment for production
-- Auto-scaling configuration
-- Failover testing records
-
----
-
-### A 1.3 — Recovery Testing
-
-**Priority**: High | **NIST**: CP-4 | **ISO**: A.5.30
-
-Recovery plans are tested periodically.
-
-**What auditors test**:
-- DR test records (date, scope, results)
-- Actual recovery time vs. RTO target
-
----
-
-## Processing Integrity — For Data Processing Services
-
-### PI 1.1-1.3 — Processing Completeness, Accuracy, and Timeliness
-
-**Priority**: Medium | **NIST**: SI-10, SI-11 | **ISO**: A.8.28
-
-System processing is complete, valid, accurate, and timely.
-
-**What auditors test**:
-- Input validation controls
-- Error handling and exception reporting
-- Reconciliation processes for data accuracy
-- SLA monitoring for timeliness
-
----
-
-## Confidentiality — For Sensitive Data
-
-### C 1.1 — Confidential Information Protection
-
-**Priority**: High | **NIST**: AC-21, SC-28 | **ISO**: A.5.14, A.8.24
-
-Confidential information is protected during processing and storage.
-
-**What auditors test**:
-- Data classification scheme
-- Encryption at rest for confidential data
-- Access restrictions based on classification
-
-### C 1.2 — Confidential Information Disposal
-
-**Priority**: Medium | **NIST**: MP-6, SI-12 | **ISO**: A.7.14, A.8.10
-
-Confidential information is disposed of when no longer needed.
-
-**What auditors test**:
-- Data retention policy
-- Evidence of data disposal (deletion records, media destruction)
-
----
-
-## Privacy — When Processing PII
-
-### P 4.2 — Privacy Notice
-
-**Priority**: Medium | **ISO**: A.5.34
-
-Privacy notice is provided and accessible.
-
-### P 6.1-6.6 — Data Subject Rights and Incident Response
-
-**Priority**: Medium (if PII in scope)
-
-Data subject requests are handled. Privacy incidents are reported.
-
-**What auditors test**:
-- Privacy policy on website
-- Process for data subject access requests (DSARs)
-- Privacy incident notification process
-- Data processing agreements with sub-processors
-
-### P 8.1 — Quality Assurance
-
-**Priority**: Low
-
-Data quality procedures are in place.