@open-agreements/open-agreements 0.2.2 → 0.3.0

package/skills/soc2-readiness/rules/control-activities.md

@@ -0,0 +1,95 @@
+# Control Activities — CC 5.1–5.3
+
+Per-criterion audit guidance for risk mitigation selection, technology controls, and policy deployment.
+
+## CC 5.1 — Risk mitigation selection
+
+**Priority**: High | **NIST**: AC-5 | **ISO**: A.5.3
+
+Auditors verify that the organization selects and deploys control activities that mitigate identified risks to acceptable levels. This is the bridge between the risk assessment (CC 3) and actual controls — each significant risk should trace to one or more controls. Segregation of duties is a key element auditors evaluate here.
+
+**What auditors test**:
+- Control activities are mapped to specific risks from the risk register (traceability)
+- Segregation of duties: conflicting responsibilities are separated across different individuals
+- Key incompatible functions identified and separated: access provisioning vs. access review, code development vs. deployment approval, payment initiation vs. payment approval
+- Compensating controls documented where full segregation isn't feasible (common in small teams)
+- Control design considers both preventive (stop it before it happens) and detective (find it after it happens) controls
+
+**Evidence to prepare**:
+- Risk-to-control mapping matrix (risk register entries linked to specific controls)
+- Segregation of duties matrix identifying incompatible functions and how they're separated
+- Compensating controls documentation for small-team exceptions
+- Control design rationale for critical risks (why this control was selected over alternatives)
+
+**Startup pitfalls**:
+- No traceability between risks and controls — controls exist but aren't linked to specific risks
+- Segregation of duties impossible with 3-person engineering team — document compensating controls instead of ignoring the requirement
+- Only preventive controls, no detective controls — if prevention fails, there's no detection
+
+---
+
+## CC 5.2 — Technology general controls
+
+**Priority**: High | **NIST**: AC-1, IA-2 | **ISO**: A.5.15, A.8.5
+
+Auditors verify that technology infrastructure supporting the control environment is itself controlled. This covers IT general controls (ITGCs): access management for infrastructure, authentication mechanisms, and the foundational technology controls that other controls depend on.
+
+**What auditors test**:
+- Infrastructure access controls: who can access production servers, databases, cloud consoles
+- Authentication strength: MFA enforced for infrastructure access (cloud console, SSH, VPN)
+- Automated controls functioning correctly: CI/CD gates, automated access reviews, scheduled scans
+- Dependency management: technology controls don't rely on manual processes that could be skipped
+- Technology control monitoring: alerts when automated controls fail or are bypassed
+
+**Evidence to prepare**:
+```bash
+# GitHub: branch protection (automated control)
+gh api repos/{owner}/{repo}/branches/main/protection | jq '{
+  required_reviews: .required_pull_request_reviews.required_approving_review_count,
+  required_checks: .required_status_checks.contexts,
+  enforce_admins: .enforce_admins.enabled
+}'
+
+# GCP: organization policies (automated guardrails)
+gcloud resource-manager org-policies list --organization={org_id} --format=json | jq '.[].constraint'
+
+# GitHub: required status checks (CI gates)
+gh api repos/{owner}/{repo}/branches/main/protection/required_status_checks | jq '.contexts'
+```
+- Infrastructure access control matrix (who has access to what, at what level)
+- Automated control inventory (CI/CD gates, automated scans, scheduled reviews)
+- Technology control failure alerting configuration
+
+**Startup pitfalls**:
+- All engineers have production database access "for debugging" — violates least privilege
+- CI/CD pipeline has no required checks — tests are optional and frequently skipped
+- Cloud console access not protected by MFA — "it's inconvenient" is not an acceptable justification
+
+---
+
+## CC 5.3 — Policy and procedure deployment
+
+**Priority**: Medium | **NIST**: PM-1, PL-1 | **ISO**: A.5.1, C.5.2
+
+Auditors verify that security policies and procedures are formalized, approved, communicated, and accessible to all relevant personnel. Policies must be living documents — reviewed periodically, updated when changes occur, and acknowledged by employees.
+
+**What auditors test**:
+- Information security policy suite exists: overarching policy plus supporting procedures
+- Policies are approved by management (signature or formal approval record)
+- Policies are reviewed at least annually and updated when significant changes occur
+- Employees can access policies (intranet, shared drive, wiki) and know where to find them
+- Policy acknowledgment: employees sign or electronically acknowledge reading policies
+- Version control: policies have version numbers, effective dates, and review dates
+
+**Evidence to prepare**:
+- Policy inventory (list of all security-related policies with version, effective date, next review date)
+- Signed management approval for each policy
+- Policy acknowledgment records (employee signatures or electronic acknowledgment log)
+- Policy distribution mechanism (shared drive link, wiki URL, HRIS integration)
+- Policy review log showing annual review was conducted with any changes noted
+
+**Startup pitfalls**:
+- Policies exist in someone's Google Drive but aren't shared or discoverable
+- No version control — impossible to prove which version was in effect during the audit period
+- Policies never reviewed after initial creation — outdated content that doesn't match current practices
+- Acknowledgment collected at onboarding but not when policies are updated

package/skills/soc2-readiness/rules/control-environment.md

@@ -0,0 +1,126 @@
+# Control Environment — CC 1.1–1.5
+
+Per-criterion audit guidance for governance, ethics, organizational structure, and accountability.
+
+## CC 1.1 — Ethics and integrity
+
+**Priority**: Medium | **NIST**: PS-1, PS-3, PS-6 | **ISO**: A.6.1, A.6.2, A.6.4
+
+Auditors assess whether the organization sets the tone from the top on integrity and ethical behavior. This isn't about having a perfect culture — it's about demonstrating that leadership has established expectations, communicated them, and created mechanisms for accountability. For startups, the code of conduct and background checks are the minimum viable evidence.
+
+**What auditors test**:
+- Code of conduct or ethics policy exists and is signed by all employees (including founders)
+- Background checks completed for employees with access to sensitive data — verify checks completed before start date
+- Whistleblower or ethics reporting mechanism exists (even a simple anonymous form counts)
+- Management demonstrates ethical tone: policies apply equally to leadership and staff
+- Sample 3-5 employee files for signed acknowledgments
+
+**Evidence to prepare**:
+- Code of conduct or ethics policy (with effective date predating audit period)
+- Signed acknowledgment records for all employees (export from HRIS or document management)
+- Background check completion records (date of check vs. start date)
+- Whistleblower policy or ethics reporting channel documentation
+- Employee handbook section covering ethical standards and consequences
+
+**Startup pitfalls**:
+- Code of conduct doesn't exist or was written after the audit period started
+- Background checks skipped for early employees and contractors
+- "We're too small for a whistleblower policy" — auditors expect one regardless of size
+
+---
+
+## CC 1.2 — Board oversight
+
+**Priority**: Medium | **NIST**: PM-1, PM-2 | **ISO**: C.5.1, C.5.3
+
+Auditors verify that governance bodies (board, advisory board, or management committee) exercise oversight of the internal control environment. For startups without a formal board, the equivalent is documented management reviews where leadership evaluates security posture and risk.
+
+**What auditors test**:
+- Board or management committee meets at regular intervals (at least quarterly)
+- Meeting minutes include discussion of security, risk, or compliance topics
+- Board members have relevant expertise or access to advisors for security/technology oversight
+- Management reporting: leadership receives periodic updates on security metrics, incidents, and compliance status
+- Charter or terms of reference define the governance body's responsibilities for internal controls
+
+**Evidence to prepare**:
+- Board or management meeting minutes from the audit period (at least quarterly)
+- Board charter or management review charter covering security oversight responsibilities
+- Security/compliance status reports presented to leadership
+- Board member biographies showing relevant expertise
+- Evidence of independent oversight (external advisors, audit committee, or independent board members)
+
+**Startup pitfalls**:
+- No documented board meetings — investor updates don't count unless they cover security governance
+- Management reviews happen informally but are never documented with minutes
+- Security is never a board/management agenda item — only discussed reactively after incidents
+
+---
+
+## CC 1.3 — Organizational structure
+
+**Priority**: Medium | **NIST**: PM-2 | **ISO**: C.5.3
+
+Auditors verify that the organization has a defined structure with clear lines of authority and reporting for security-related functions. Someone must be accountable for the security program — even if it's a shared responsibility in a small team, it should be documented.
+
+**What auditors test**:
+- Organizational chart showing reporting lines for security function
+- Named security owner (CISO, VP Engineering, CTO, or designated security lead)
+- Reporting line: security function reports to management with authority to act
+- Segregation of duties: key security functions (access management, change approval, incident response) are not concentrated in one person without compensating controls
+- Job descriptions include security responsibilities where applicable
+
+**Evidence to prepare**:
+- Current organizational chart (with date)
+- Security program charter or policy naming the responsible individual
+- Job descriptions for security-relevant roles (even if security is one of several responsibilities)
+- RACI matrix for key security processes (access management, incident response, change control)
+
+---
+
+## CC 1.4 — Competence commitment
+
+**Priority**: High | **NIST**: AT-2, PS-3 | **ISO**: A.6.1, A.6.3
+
+Auditors verify that the organization hires competent people and invests in keeping their skills current through training. Security awareness training is the most commonly tested element — expect auditors to check completion rates and content relevance.
+
+**What auditors test**:
+- Security awareness training completed by all employees within audit period (100% completion expected)
+- Training content covers: phishing recognition, password hygiene, incident reporting, acceptable use
+- New hire training completed within first 30 days of employment
+- Role-specific training for security-critical positions (e.g., secure coding for developers)
+- Training records are maintained with dates, participants, and completion status
+
+**Evidence to prepare**:
+- Training completion records with dates (export from LMS, Google Classroom, or training platform)
+- Training content outline or syllabus covering security topics
+- Phishing simulation results (if applicable — demonstrates training effectiveness)
+- New hire onboarding checklist showing security training step with deadline
+- Certificates or completion records for role-specific training
+
+**Startup pitfalls**:
+- No formal training — "we talk about security in all-hands" isn't documented or verifiable
+- Training completed by 80% of employees — the 20% gap is a finding
+- Training content is generic and doesn't cover the organization's specific policies
+- No tracking mechanism — "everyone did it" without records is unverifiable
+
+---
+
+## CC 1.5 — Accountability
+
+**Priority**: Medium | **NIST**: PS-3, PS-4 | **ISO**: A.6.4, A.6.5
+
+Auditors verify that individuals are held accountable for their internal control responsibilities. This connects ethics (CC 1.1) with consequences — if someone violates security policy, there's a defined process for addressing it. Accountability also means performance evaluations include security responsibilities.
+
+**What auditors test**:
+- Disciplinary process exists for security policy violations (documented in employee handbook)
+- The process is communicated to all employees (typically at onboarding and via training)
+- Performance evaluations include security-related responsibilities for relevant roles
+- Consequences are applied consistently — leadership is not exempt
+- Termination procedures include security considerations (access revocation, NDA reminders)
+
+**Evidence to prepare**:
+- Employee handbook section covering disciplinary process for policy violations
+- Signed policy acknowledgment forms (proving employees know the consequences)
+- Performance review template showing security-related criteria (for security-relevant roles)
+- Termination checklist with security steps (access revocation, equipment return, NDA reminder)
+- Exit interview template covering ongoing confidentiality obligations

package/skills/soc2-readiness/rules/logical-access.md

@@ -0,0 +1,264 @@
+# Logical and Physical Access — CC 6.1–6.8
+
+Per-criterion audit guidance for access control, provisioning, physical security, threat detection, and data protection.
+
+## 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
+
+Auditors assess whether the organization restricts system access to authorized users through layered controls — identity verification, role-based permissions, encryption, and session management. The focus is on whether controls work together as a system, not just whether individual tools are configured.
+
+**What auditors test**:
+- Sample 10-15 user accounts across systems: verify each account's access matches the person's documented role
+- Confirm MFA is enforced (not just available) on all systems storing or processing sensitive data
+- Verify encryption at rest (AES-256 or equivalent) for databases, object storage, and backups
+- Check for shared or generic accounts — each should be documented with a named owner
+- Test that failed login attempts are logged and trigger alerts after threshold (typically 5-10 attempts)
+
+**Evidence to prepare**:
+```bash
+# Google Workspace: user list with MFA enforcement status
+gam print users fields primaryEmail,name,orgUnitPath,isAdmin,isEnforcedIn2Sv
+
+# GitHub: org-level security settings
+gh api orgs/{org} | jq '{two_factor_requirement_enabled, default_repository_permission}'
+
+# GCP: IAM bindings showing role assignments
+gcloud projects get-iam-policy {project} --format=json | jq '.bindings[] | {role, members}'
+
+# TLS configuration check
+openssl s_client -connect {host}:443 -tls1_2 < /dev/null 2>&1 | grep "Protocol\|Cipher"
+
+# Azure: list role assignments
+az role assignment list --all --output json | jq '.[] | {principalName, roleDefinitionName, scope}'
+```
+
+**Startup pitfalls**:
+- Using personal Gmail/GitHub accounts for company systems — creates access gaps when people leave
+- MFA "enabled" but not "enforced" — users can skip enrollment indefinitely
+- Encryption at rest assumed because "cloud provider handles it" — auditors want explicit confirmation per service
+- Shared credentials for CI/CD, monitoring, or SaaS tools with no documented owner
+
+---
+
+## CC 6.2 — Access provisioning and deprovisioning
+
+**Priority**: Critical | **NIST**: AC-2, PS-4, PS-5 | **ISO**: A.5.18, A.6.5
+
+Auditors verify that access is granted through a documented authorization process and revoked promptly when no longer needed. The provisioning-to-deprovisioning lifecycle is one of the most frequently tested areas in a SOC 2 audit — expect auditors to trace individual employees from hire to termination.
+
+**What auditors test**:
+- Sample 5-10 new hires: verify access was authorized before provisioning (ticket, email approval, or workflow)
+- Sample 5-10 terminations: verify access was revoked within 24-48 hours across all systems
+- Cross-reference HR termination dates with last-active dates in IdP, GitHub, cloud consoles, and SaaS tools
+- Check for orphaned accounts — active accounts with no corresponding current employee
+- Verify that access request and revocation processes are documented, not just tribal knowledge
+
+**Evidence to prepare**:
+```bash
+# Google Workspace: identify potentially orphaned accounts
+gam print users fields primaryEmail,lastLoginTime,suspended | \
+  awk -F',' '$2 < "2024-01-01" && $3 != "True" {print $1, $2}'
+
+# GitHub: org members with activity dates
+gh api orgs/{org}/members --paginate | jq '.[] | {login, type}'
+
+# Cross-reference terminated employees (manual step):
+# Export HR termination list → compare against active accounts in each system
+```
+- HR-to-IT onboarding workflow documentation (ticketing system or checklist)
+- Termination checklist with explicit IT deprovisioning steps
+- Access request approval records (email threads, Jira tickets, or HRIS workflow logs)
+
+**Startup pitfalls**:
+- No formal offboarding process — founder "remembers" to revoke access but misses secondary systems
+- Deprovisioning only covers email — GitHub, cloud console, SaaS tools, and API keys are forgotten
+- Relying on quarterly access reviews to catch terminations instead of event-driven revocation
+
+---
+
+## CC 6.3 — Access modification
+
+**Priority**: High | **NIST**: AC-2, AC-6 | **ISO**: A.5.15, A.5.18
+
+When employees change roles, get promoted, or shift teams, their access should be reviewed and adjusted. Auditors look for permission accumulation — people who retain old access after moving to a new role, gradually amassing broader access than any single role requires.
+
+**What auditors test**:
+- Sample 3-5 internal transfers or promotions: verify previous role's access was reviewed and excess removed
+- Check for users with permissions spanning multiple business functions (e.g., engineering + finance access)
+- Verify that role changes trigger an access review workflow, not just additive provisioning
+- Look for dormant permissions: access granted months ago that hasn't been used
+
+**Evidence to prepare**:
+```bash
+# GCP: identify users with multiple high-privilege roles
+gcloud projects get-iam-policy {project} --format=json | \
+  jq '[.bindings[] | .members[] as $m | {member: $m, role: .role}] | group_by(.member) | map(select(length > 2))'
+
+# GitHub: users who are members of multiple teams
+gh api orgs/{org}/members --paginate | jq '.[].login' | while read user; do
+  teams=$(gh api orgs/{org}/members/$user/teams 2>/dev/null | jq length)
+  echo "$user: $teams teams"
+done
+```
+- Access review records from most recent quarterly review cycle
+- Documentation of role-change access review process
+
+---
+
+## CC 6.4 — Physical access controls
+
+**Priority**: High | **NIST**: PE-2, PE-3, PE-6 | **ISO**: A.7.2, A.7.4
+
+Physical access to facilities housing systems and data must be restricted to authorized personnel. For cloud-native companies, this primarily means relying on cloud provider SOC 2 reports for data center controls while managing office and endpoint physical security directly.
+
+**What auditors test**:
+- For on-premises: visitor logs, badge access records, security camera footage availability
+- For cloud-hosted: confirm cloud provider SOC 2 Type II report covers physical security and review for exceptions
+- Office security: verify that server rooms, network closets, or sensitive areas have restricted access
+- Remote workforce: endpoint encryption and screen lock policies serve as compensating controls
+- Verify that physical access lists are reviewed periodically (at least annually)
+
+**Evidence to prepare**:
+```bash
+# macOS: verify FileVault disk encryption
+fdesetup status
+
+# macOS: verify screen lock is configured
+system_profiler SPConfigurationProfileDataType 2>/dev/null | grep -A5 "maxInactivity"
+```
+- Cloud provider SOC 2 Type II reports (AWS, GCP, Azure) — specifically the physical security sections
+- Office badge access logs or visitor sign-in records (if applicable)
+- Clean desk policy documentation
+- Remote work security policy with endpoint requirements
+
+---
+
+## CC 6.5 — Asset disposal
+
+**Priority**: Medium | **NIST**: MP-6 | **ISO**: A.7.10, A.7.14
+
+When hardware, media, or storage containing sensitive data is decommissioned, the organization must ensure data is irrecoverably destroyed. Auditors verify that disposal is documented and that data can't be recovered from retired assets.
+
+**What auditors test**:
+- Inventory of disposed hardware and storage media during the audit period
+- Certificates of destruction from disposal vendors (for physical media)
+- Verification that cloud storage and database instances are fully deleted, not just "stopped"
+- Data wiping procedures for laptops and devices before reassignment or disposal
+
+**Evidence to prepare**:
+```bash
+# GCP: list deleted instances (audit log)
+gcloud logging read 'resource.type="gce_instance" AND protoPayload.methodName="v1.compute.instances.delete"' \
+  --limit=20 --format=json | jq '.[].protoPayload | {timestamp: .requestMetadata.requestAttributes.time, instance: .resourceName}'
+
+# Azure: activity log for resource deletions
+az monitor activity-log list --offset 90d --query "[?operationName.value=='Microsoft.Compute/virtualMachines/delete']" --output json
+```
+- Hardware disposal log (serial number, date, method, witness)
+- Certificates of destruction from e-waste or shredding vendors
+- Policy document covering data sanitization standards (NIST 800-88 reference)
+
+---
+
+## CC 6.6 — Threat and vulnerability detection
+
+**Priority**: Critical | **NIST**: RA-5, SI-4 | **ISO**: A.8.8, A.8.16
+
+Auditors verify that the organization proactively identifies vulnerabilities and threats before they're exploited. This means automated scanning, not just reactive patching. Expect auditors to ask for scan reports and remediation timelines.
+
+**What auditors test**:
+- Vulnerability scanning: automated scans running at least weekly against production infrastructure
+- Scan coverage: all production-facing systems are in scope, not just a subset
+- Remediation SLAs: critical vulnerabilities patched within 14-30 days, with evidence of tracking
+- Penetration testing: at least annual, with documented findings and remediation
+- Dependency scanning: automated checks for known vulnerabilities in third-party libraries
+
+**Evidence to prepare**:
+```bash
+# GitHub: Dependabot alerts summary
+gh api repos/{owner}/{repo}/dependabot/alerts --jq '[.[] | {severity: .security_advisory.severity, state}] | group_by(.severity) | map({severity: .[0].severity, count: length})'
+
+# GitHub: code scanning alerts
+gh api repos/{owner}/{repo}/code-scanning/alerts --jq '[.[] | {severity: .rule.severity, state}] | group_by(.state) | map({state: .[0].state, count: length})'
+
+# GCP: Security Command Center findings
+gcloud scc findings list organizations/{org_id} --format=json | jq '.[].finding | {category, severity, state}'
+```
+- Most recent vulnerability scan report (redacted if needed)
+- Penetration test report and remediation status
+- Vulnerability management policy with remediation SLAs by severity
+
+**Startup pitfalls**:
+- Dependabot enabled but alerts ignored — hundreds of unresolved alerts is worse than no scanner
+- No penetration test ever conducted — budget at least one external test before audit
+- Scanning only covers web app, not infrastructure, containers, or dependencies
+
+---
+
+## CC 6.7 — Transmission security
+
+**Priority**: High | **NIST**: SC-8 | **ISO**: A.5.14, A.8.24
+
+Data in transit must be protected from interception and tampering. Auditors verify that TLS/encryption is enforced on all channels carrying sensitive data — not just the main web app, but internal service communication, API endpoints, and data transfers.
+
+**What auditors test**:
+- TLS 1.2+ enforced on all public-facing endpoints (TLS 1.0/1.1 disabled)
+- Internal service-to-service communication encrypted (mutual TLS or service mesh)
+- Email encryption for sensitive communications (TLS enforcement on mail servers)
+- File transfer mechanisms use encrypted protocols (SFTP, SCP — not plain FTP)
+- Certificate management: no expired certificates, automated renewal preferred
+
+**Evidence to prepare**:
+```bash
+# Check TLS version and cipher on production endpoint
+openssl s_client -connect {host}:443 -tls1_2 < /dev/null 2>&1 | grep "Protocol\|Cipher"
+
+# Verify TLS 1.0/1.1 are rejected
+openssl s_client -connect {host}:443 -tls1 < /dev/null 2>&1 | grep "alert"
+openssl s_client -connect {host}:443 -tls1_1 < /dev/null 2>&1 | grep "alert"
+
+# GCP: SSL policy check
+gcloud compute ssl-policies describe {policy-name} --format=json | jq '{minTlsVersion, profile}'
+
+# Check certificate expiration
+echo | openssl s_client -connect {host}:443 2>/dev/null | openssl x509 -noout -dates
+```
+- Network architecture diagram showing encryption boundaries
+- TLS configuration documentation for internal services
+
+---
+
+## CC 6.8 — Malware prevention
+
+**Priority**: High | **NIST**: SI-2, SI-3 | **ISO**: A.8.7, A.8.19
+
+Auditors verify that endpoint and server protection mechanisms detect, prevent, and respond to malware. For cloud-native organizations, this extends to container image scanning and CI/CD pipeline protections.
+
+**What auditors test**:
+- Endpoint protection deployed on all company-managed devices (laptops, workstations)
+- Endpoint agent is active and reporting — not just installed but disabled
+- Server/container protection: image scanning in CI/CD, runtime protection in production
+- Patch management: OS and application patches applied within defined SLAs
+- Email filtering: anti-phishing and attachment scanning on inbound email
+
+**Evidence to prepare**:
+```bash
+# macOS: check for endpoint protection agent
+ls /Library/Application\ Support/ | grep -i -E "(crowdstrike|sentinel|carbon|defender)"
+
+# macOS: verify OS is current
+sw_vers
+
+# GitHub: check for container scanning in CI
+gh api repos/{owner}/{repo}/actions/workflows --jq '.workflows[].name' | grep -i -E "scan|security|snyk|trivy"
+```
+- Endpoint protection dashboard export showing device coverage and status
+- Patch management report showing compliance percentage
+- Container image scanning results from CI/CD pipeline
+- Email security configuration (SPF, DKIM, DMARC records)
+
+**Startup pitfalls**:
+- "We use Macs, Macs don't get malware" — auditors expect endpoint protection regardless of OS
+- Endpoint agent installed during onboarding but never verified as running
+- No patch management cadence — relying on users to update their own devices

package/skills/soc2-readiness/rules/monitoring-activities.md

@@ -0,0 +1,66 @@
+# Monitoring Activities — CC 4.1–4.2
+
+Per-criterion audit guidance for ongoing monitoring and deficiency evaluation.
+
+## CC 4.1 — Ongoing monitoring
+
+**Priority**: Medium | **NIST**: CA-7, PM-6 | **ISO**: C.9.1
+
+Auditors verify that the organization continuously monitors the effectiveness of its internal controls — not just at audit time, but throughout the year. This means management has mechanisms to detect when controls degrade, stop working, or are bypassed. The distinction from CC 7.2 (anomaly detection) is that CC 4.1 covers monitoring of the controls themselves, not just the systems they protect.
+
+**What auditors test**:
+- Management reviews of control effectiveness at defined intervals (at least quarterly)
+- Automated monitoring: alerts when critical controls fail (e.g., branch protection disabled, MFA turned off, backups stop running)
+- Key metrics tracked over time: access review completion rates, vulnerability remediation timelines, training completion percentages
+- Internal audit or self-assessment conducted during the audit period
+- Control monitoring results are reported to management with trends and exceptions
+
+**Evidence to prepare**:
+```bash
+# GitHub: verify branch protection is still active (control monitoring)
+gh api repos/{owner}/{repo}/branches/main/protection --jq '{enforced: true}' 2>&1
+
+# GCP: verify monitoring policies are active (alerting on control failures)
+gcloud monitoring policies list --format=json | jq '.[] | {displayName, enabled}'
+
+# GCP: check backup automation status
+gcloud sql instances describe {instance} --format=json | jq '.settings.backupConfiguration'
+```
+- Management review meeting minutes discussing control effectiveness
+- Control monitoring dashboard or metrics report (quarterly at minimum)
+- Internal audit or self-assessment report from the audit period
+- Exception log: instances where controls failed or were bypassed, with resolution
+
+**Startup pitfalls**:
+- Controls implemented at audit prep time but no ongoing monitoring to verify they keep working
+- Management reviews are informal conversations with no documentation
+- No alerting on control failures — branch protection silently disabled for months
+- Metrics collected but never reviewed or acted upon
+
+---
+
+## CC 4.2 — Deficiency evaluation and remediation
+
+**Priority**: Medium | **NIST**: CA-2 | **ISO**: C.9.2.1
+
+Auditors verify that when control deficiencies are identified — through monitoring, incidents, audits, or testing — they are evaluated for severity, tracked to remediation, and reported to management. A deficiency that's identified but never fixed is arguably worse than one never discovered, because it demonstrates awareness without action.
+
+**What auditors test**:
+- Deficiencies identified through monitoring (CC 4.1), incidents (CC 7.3), or assessments are logged
+- Each deficiency has: severity rating, owner, remediation plan, and target completion date
+- Remediation is tracked to completion — not just planned but verified as resolved
+- Management receives reports on open deficiencies and remediation progress
+- Root cause analysis conducted for significant deficiencies to prevent recurrence
+
+**Evidence to prepare**:
+- Deficiency tracking log or remediation tracker (Jira, spreadsheet, or GRC tool)
+- Remediation evidence for deficiencies closed during the audit period
+- Management reports showing deficiency status and trends
+- Root cause analysis documentation for significant deficiencies
+- Corrective action verification records (confirming fixes actually work)
+
+**Startup pitfalls**:
+- Deficiencies noted during previous audit but not remediated by the next one — repeat findings
+- No formal tracking — issues discussed in Slack but never logged or followed through
+- Remediation planned but not verified — "we fixed it" without testing the fix
+- No root cause analysis — same type of deficiency keeps recurring