@open-agreements/open-agreements 0.2.0 → 0.2.2

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.

package/skills/safe/SKILL.md

@@ -159,3 +159,12 @@ Use `list_templates` (MCP) or `list --json` (CLI) for the latest inventory and f
 - YC SAFE templates are licensed under CC-BY-ND-4.0 — you can fill them for your own use but must not redistribute modified versions of the template itself
 - SAFEs are not debt instruments — they convert to equity in a future priced 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.

package/skills/services-agreement/SKILL.md

@@ -154,3 +154,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/soc2-readiness/CONNECTORS.md

@@ -0,0 +1,23 @@
+# Connectors
+
+## How tool references work
+
+This skill uses `~~category` placeholders for optional integrations. The skill works without any connectors configured — they enhance the experience when available.
+
+## Connectors for this skill
+
+| Category | Placeholder | Recommended server | Other options |
+|----------|-------------|-------------------|---------------|
+| Compliance data | `~~compliance` | Compliance MCP server (planned — not yet available) | Local `compliance/` directory files |
+
+### Local compliance data (current default)
+
+If the `compliance/` directory exists with SOC 2 test metadata, the skill reads those directly. No MCP server needed.
+
+### Compliance MCP server (planned)
+
+A dedicated compliance MCP server with live SOC 2 test pass/fail data and readiness scores is planned but not yet available. When released, it will be installable as a standard MCP server. Until then, the skill operates in local-data or reference-only mode.
+
+### Fallback: Reference only
+
+Without any connector, the skill uses embedded criteria mapping and checklists. No organization-specific status data is available in this mode.