@open-agreements/open-agreements 0.2.0 → 0.2.2

package/skills/soc2-readiness/SKILL.md

@@ -0,0 +1,289 @@
+---
+name: soc2-readiness
+description: >-
+  Assess SOC 2 Type II readiness. Map Trust Services Criteria to controls,
+  identify gaps, and build a remediation plan. Uses NIST SP 800-53 (public
+  domain) as canonical reference with SOC 2 criterion cross-mapping.
+license: MIT
+compatibility: >-
+  Works with any AI agent. Enhanced with compliance MCP server for live
+  status data. Falls back to embedded reference material when no live data
+  available.
+metadata:
+  author: open-agreements
+  version: "0.1.0"
+  frameworks:
+    - SOC 2 Type II
+    - NIST SP 800-53 Rev 5
+    - ISO 27001:2022
+---
+
+# SOC 2 Readiness Assessment
+
+Assess readiness for a SOC 2 Type II audit. This skill walks through the Trust Services Criteria, identifies gaps, maps to NIST controls, and generates a prioritized remediation plan.
+
+## Security Model
+
+- **No scripts executed** — markdown-only procedural guidance
+- **No secrets required** — works with reference checklists
+- **IP-clean** — AICPA Trust Services Criteria are publicly cited; descriptions are original writing
+- **Evidence stays local** — all collection outputs go to local filesystem
+
+## When to Use
+
+Activate this skill when:
+
+1. **First SOC 2 preparation** — building controls from scratch for initial Type I or Type II
+2. **Pre-audit readiness check** — 4-8 weeks before audit window opens
+3. **Gap analysis after scope change** — new systems, services, or trust criteria added
+4. **Remediation planning** — translating audit findings into actionable work items
+5. **Dual-framework mapping** — already pursuing ISO 27001 and need SOC 2 overlap analysis
+
+Do NOT use for:
+- ISO 27001 internal audit — use `iso-27001-internal-audit`
+- Evidence collection mechanics — use `iso-27001-evidence-collection`
+- Contract review — use legal agreement skills
+
+## Core Concepts
+
+### Trust Services Criteria (TSC)
+
+SOC 2 is organized around 5 Trust Services Categories. **Security (CC)** is always in scope; others are optional based on your service:
+
+| Category | Criteria | When Required |
+|----------|----------|---------------|
+| **Security** (CC) | CC 1-9 (33 criteria) | Always required |
+| **Availability** (A) | A 1.1-1.3 (3 criteria) | SaaS with uptime SLAs |
+| **Processing Integrity** (PI) | PI 1.1-1.5 (4 criteria) | Data processing services |
+| **Confidentiality** (C) | C 1.1-1.2 (2 criteria) | Handling confidential data |
+| **Privacy** (P) | P 4-8 (7 criteria) | PII processing |
+
+### SOC 2 vs. ISO 27001
+
+| Dimension | SOC 2 | ISO 27001 |
+|-----------|-------|-----------|
+| Governing body | AICPA | ISO/IEC |
+| Geography | Primarily US/Canada | Global |
+| Type | Attestation report by CPA | Certification by audit body |
+| Scope | Service-specific | Organization-wide ISMS |
+| Controls | Flexible (you define) | 93 Annex A controls |
+| Output | SOC 2 report (restricted/general use) | Certificate |
+| Overlap | ~70% overlap with ISO 27001 Annex A | ~70% overlap with SOC 2 CC |
+
+### Decision Tree: Scope Selection
+
+```
+What service are you getting audited on?
+├── SaaS product → Security + Availability (+ Confidentiality if you handle sensitive data)
+├── Data processing → Security + Processing Integrity + Confidentiality
+├── Infrastructure → Security + Availability
+├── API service → Security (+ PI if you transform data)
+│
+Do you handle PII?
+├── YES → Add Privacy category
+├── NO → Skip Privacy
+│
+Do you have uptime SLAs?
+├── YES → Include Availability
+├── NO → Optional (but customers expect it for SaaS)
+```
+
+## Step-by-Step Workflow
+
+### Step 1: Define Scope and Categories
+
+1. **Identify the service** being audited (product name, description, boundaries)
+2. **Select Trust Services Categories** using the decision tree above
+3. **Define system boundaries**: infrastructure, software, people, procedures, data
+4. **Document sub-service organizations** (cloud providers, payment processors, etc.)
+5. **Determine audit type**: Type I (point-in-time) or Type II (period of time, usually 6-12 months)
+
+### Step 2: Assess Current State
+
+For each applicable Common Criterion (CC), assess whether controls are:
+- **Designed** — control exists on paper
+- **Implemented** — control is operating
+- **Effective** — control achieves its objective (evidence exists)
+
+```
+# If compliance MCP is available:
+check_compliance_status(framework="soc2")
+```
+
+### Step 3: Map Controls to Criteria
+
+Each CC maps to specific NIST controls. Use this mapping to identify what you need:
+
+#### CC 1 — Control Environment
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 1.1 | Integrity and ethics | PS-1, PS-3, PS-6 | A.6.1, A.6.2, A.6.4 |
+| CC 1.2 | Board oversight | PM-1, PM-2 | C.5.1, C.5.3 |
+| CC 1.3 | Organizational structure | PM-2 | C.5.3 |
+| CC 1.4 | Competence commitment | AT-2, PS-3 | A.6.1, A.6.3 |
+| CC 1.5 | Accountability | PS-3, PS-4 | A.6.4, A.6.5 |
+
+#### CC 2 — Communication and Information
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 2.1 | Internal information | AU-2, SI-5 | C.7.5.1 |
+| CC 2.2 | Internal communication | PM-2, AT-2 | C.7.4, A.6.3 |
+| CC 2.3 | External communication | PM-1 | A.5.14 |
+
+#### CC 3 — Risk Assessment
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 3.1 | Risk objectives | PM-9, RA-1 | C.6.1.1 |
+| CC 3.2 | Risk identification | RA-3 | C.6.1.2, C.8.2 |
+| CC 3.3 | Fraud risk | RA-3 | C.6.1.2 |
+| CC 3.4 | Change impact | RA-3, CM-4 | C.6.1.2, A.8.9 |
+
+#### CC 4 — Monitoring Activities
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 4.1 | Ongoing monitoring | CA-7, PM-6 | C.9.1 |
+| CC 4.2 | Deficiency evaluation | CA-2 | C.9.2.1 |
+
+#### CC 5 — Control Activities
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 5.1 | Risk mitigation | AC-5 | A.5.3 |
+| CC 5.2 | Technology controls | AC-1, IA-2 | A.5.15, A.8.5 |
+| CC 5.3 | Policy deployment | PM-1, PL-1 | A.5.1, C.5.2 |
+
+#### CC 6 — Logical and Physical Access
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 6.1 | Access control | AC-2, AC-3, IA-2, SC-28 | A.5.15, A.8.5, A.8.24 |
+| CC 6.2 | Access provisioning | AC-2, PS-4, PS-5 | A.5.18, A.6.5 |
+| CC 6.3 | Access modification | AC-2, AC-6 | A.5.15, A.5.18 |
+| CC 6.4 | Physical access | PE-2, PE-3, PE-6 | A.7.2, A.7.4 |
+| CC 6.5 | Asset disposal | MP-6 | A.7.10, A.7.14 |
+| CC 6.6 | Threat detection | RA-5, SI-4 | A.8.8, A.8.16 |
+| CC 6.7 | Transmission security | SC-8 | A.5.14, A.8.24 |
+| CC 6.8 | Malware prevention | SI-2, SI-3 | A.8.7, A.8.19 |
+
+#### CC 7 — System Operations
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 7.1 | Operational monitoring | CM-6, RA-5 | A.8.9, A.8.8 |
+| CC 7.2 | Anomaly detection | AU-6, SI-4 | A.8.15, A.8.16 |
+| CC 7.3 | Incident response | IR-4 | A.5.24, A.5.25 |
+| CC 7.4 | Incident management | IR-5, IR-6 | A.5.25, A.5.26 |
+| CC 7.5 | Recovery | CP-4, CP-9, CP-10 | A.5.30, A.8.13 |
+
+#### CC 8 — Change Management
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 8.1 | Change control | CM-3, CM-5, SA-3 | A.8.9, A.8.25, A.8.32 |
+
+#### CC 9 — Risk Mitigation
+
+| Criterion | Focus | NIST Controls | ISO Cross-Reference |
+|-----------|-------|---------------|---------------------|
+| CC 9.1 | Risk mitigation | CP-2, RA-7 | A.5.30, C.6.1.3 |
+| CC 9.2 | Vendor management | AC-20, SA-9 | A.5.19, A.5.22 |
+
+### Step 4: Generate Gap Analysis
+
+For each criterion, document:
+
+```markdown
+## Gap: [CC x.x] — [Brief description]
+
+**Current State**: [What exists today]
+**Required State**: [What the auditor expects]
+**Gap**: [What's missing]
+**Remediation**:
+1. [Specific action item]
+2. [Specific action item]
+**Priority**: Critical / High / Medium / Low
+**Effort**: [Days/weeks to remediate]
+**Owner**: [Person responsible]
+**Evidence Needed**: [What to collect after fix]
+```
+
+### Step 5: Build Remediation Plan
+
+Prioritize gaps by:
+1. **Critical** — Audit will fail without this (CC 6.1, 6.2, 7.2, 7.5, 8.1)
+2. **High** — Likely finding if not addressed (CC 1.4, 3.2, 6.6, 7.3)
+3. **Medium** — Auditor will note but may not be a finding
+4. **Low** — Best practice, not strictly required
+
+### Step 6: Readiness Report
+
+Generate a structured readiness assessment:
+
+1. **Executive summary** — overall readiness percentage, estimated time to audit-ready
+2. **Scope** — service description, trust categories, audit type
+3. **Control matrix** — all applicable criteria with status (designed/implemented/effective)
+4. **Gap analysis** — prioritized list of gaps with remediation plan
+5. **Timeline** — remediation milestones leading to audit window
+
+## Quick Reference: Top SOC 2 Failures
+
+| # | Criterion | Common Failure | Fix |
+|---|-----------|---------------|-----|
+| 1 | CC 6.1 | MFA not universal | Enforce MFA on all systems with sensitive data |
+| 2 | CC 6.2 | Access not revoked on termination | Automate deprovisioning; verify within 24h |
+| 3 | CC 7.2 | No log monitoring | Configure alerts for auth failures, privilege changes |
+| 4 | CC 8.1 | No change management | Require PR reviews; document deployment process |
+| 5 | CC 7.5 | Backups never tested | Restore from backup quarterly; document results |
+| 6 | CC 3.2 | No risk assessment | Conduct and document annual risk assessment |
+| 7 | CC 6.6 | No vulnerability scanning | Deploy automated scanning; remediate criticals in 30d |
+| 8 | CC 1.4 | Security training incomplete | Require annual training; track completion |
+| 9 | CC 9.2 | Vendor risk not assessed | Maintain vendor register; collect SOC 2 reports |
+| 10 | CC 7.3 | No incident response plan | Document plan; conduct tabletop exercise |
+
+## DO / DON'T
+
+### DO
+- Start with Security (CC) criteria — they're always required and cover ~80% of effort
+- Map to ISO 27001 if pursuing both frameworks — ~70% control overlap
+- Collect evidence throughout the audit period, not just at audit time
+- Include sub-service organizations in your description
+- Define the audit period before starting evidence collection
+
+### DON'T
+- Include trust categories you can't support — better to pass on fewer than fail on more
+- Assume Type I is "easy" — it requires all controls to be designed and implemented
+- Forget the system description — auditors review this first and use it to scope their testing
+- Use generic/template control descriptions — auditors expect your controls to match your actual environment
+- Ignore complementary user entity controls (CUECs) — your customers need to know their responsibilities
+
+## Troubleshooting
+
+| Problem | Solution |
+|---------|----------|
+| First SOC 2, no existing controls | Start with CC 6 (access) and CC 8 (change management) — fastest to implement |
+| Already have ISO 27001 | Map Annex A controls to SOC 2 CC; ~70% are already covered |
+| Auditor requests evidence we don't have | Collect it now; document the process; note in description if control was implemented mid-period |
+| Multiple environments (prod/staging/dev) | Only production environment needs to be in scope; document boundaries clearly |
+| Sub-service org (AWS/GCP/Azure) | Use SOC 2 Type II report from the provider; document which controls they cover |
+
+## Rules
+
+For detailed SOC 2-specific guidance:
+
+| File | Coverage |
+|------|----------|
+| `rules/trust-services.md` | Detailed per-criterion guidance for all 5 trust service categories |
+
+## Attribution
+
+SOC 2 criteria mapping and readiness procedures developed with [Internal ISO Audit](https://internalisoaudit.com) (Hazel Castro, ISO 27001 Lead Auditor, 14+ years, 100+ audits).
+
+## Runtime Detection
+
+1. **Compliance MCP server available** (best) — Live SOC 2 status, test pass/fail data, evidence gaps
+2. **Local compliance data available** (good) — Reads `compliance/` directory with SOC 2 test metadata
+3. **Reference only** (baseline) — Uses embedded criteria mapping and checklists

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

@@ -0,0 +1,230 @@
+# 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.

package/skills/venture-financing/SKILL.md

@@ -167,3 +167,12 @@ Use `list_templates` (MCP) or `list --json` (CLI) for the latest inventory and f
 - NVCA model documents are licensed under CC-BY-4.0
 - These documents are typically used together as a suite for a priced equity round
 - 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.