@monoes/monomindcli 2.15.3 → 2.15.5

package/org-skills/soc2-compliance/references/soc2_audit_playbook.md

@@ -0,0 +1,188 @@
+# SOC 2 Type II Audit Playbook
+
+This reference answers exactly one decision: **how do we prepare for and operate the SOC 2 Type II examination cycle — the 6-12 month observation period that produces the bound SOC 2 report?**
+
+Pair with this skill's Python tools (`control_matrix_builder.py`, `evidence_tracker.py`, `gap_analyzer.py`) and `compliance-os/scripts/audit_simulator.py` for mock-audit preparation.
+
+## Key Difference from ISO Audits
+
+SOC 2 is an **AICPA attestation**, not an ISO certification. Implications:
+
+- Performed by a licensed CPA firm (not a certification body)
+- Type I: design effectiveness at a point in time (snapshot)
+- Type II: operating effectiveness over a period (typically 6-12 months) — the report enterprise buyers actually want
+- Output: bound report distributed under NDA, not a public certificate
+- Renewed annually (continuous Type II reports rather than 3-year cert cycle)
+- **The customer (your buyer) cares about the report's "no exceptions" verdict on the Trust Services Criteria**
+
+SOC 2 is heavily about **evidence sampling over the observation period** — your control must operate consistently for the full period, not just on audit day.
+
+## When to Use This Playbook
+
+- Type I readiness (point-in-time snapshot before first Type II)
+- Type II readiness (annual; observation period typically 6-12 months)
+- Pre-bid response to enterprise procurement asking for "SOC 2 Type II"
+- Audit firm scoping discussion
+- Quarterly internal pre-audit during Type II observation period
+- New control implementation during observation period (timing impacts report)
+
+## The Five Trust Services Criteria (TSC)
+
+SOC 2 uses the 2017 TSC as updated in 2022. Always-included is Security; the other 4 are elective based on customer requirements:
+
+| TSC | Always required? | What it covers |
+|---|---|---|
+| **Security (Common Criteria CC1-CC9)** | YES — always | Common criteria across all TSC categories |
+| **Availability (A1)** | Optional | System available for operation + use as committed |
+| **Processing Integrity (PI1)** | Optional | System processing complete + valid + accurate + timely + authorized |
+| **Confidentiality (C1)** | Optional | Information designated as confidential is protected |
+| **Privacy (P1-P8)** | Optional | Personal information collected + used + retained + disclosed per privacy notice |
+
+**Common scoping:**
+- Pure infrastructure SaaS: Security + Availability + Confidentiality
+- SaaS handling consumer data: + Privacy
+- SaaS processing financial / sensitive data: + Processing Integrity
+- B2B SaaS with no consumer data: typically Security + Availability + Confidentiality
+
+## The Type II Workflow (12-month cycle)
+
+```
+[ Month 0: Type I if needed ] -> [ Month 1-2: Pre-observation prep ]
+                                            |
+                                            v
+[ Month 3-9: Observation period (audit firm samples evidence) ]
+                                            |
+                                            v
+[ Month 10: Field testing + walkthroughs ] -> [ Month 11: Report draft + management response ]
+                                            |
+                                            v
+[ Month 12: Final report issued ]
+```
+
+### Pre-Observation Phase (Months 1-2)
+
+Critical setup work. Audit firm walks through:
+
+- Scoping decisions (which TSC, which systems, which entities)
+- Description of system per AICPA AT-C 205 — narrative + boundaries + components
+- Mapping each in-scope control to TSC criteria
+- Defining sampling approach + frequency
+
+**Tip:** if you're implementing new controls during this phase, do so BEFORE the observation period starts. New controls mid-observation create gaps in the "operated consistently" assertion.
+
+### Observation Period (Months 3-9)
+
+The audit firm samples evidence from this period. You operate normally; evidence is captured and preserved.
+
+**Critical disciplines:**
+
+1. **Don't change controls mid-period** without documented change management
+2. **Don't skip controls** even for one cycle (quarterly access review skipped one quarter = a likely exception in the report)
+3. **Capture evidence in real-time** — not assembled retrospectively at audit time
+4. **Document every exception** — exceptions are not death sentences if management remediation is documented
+
+### Field Testing (Month 10)
+
+The audit firm pulls samples:
+
+- For each control, pulls samples from the observation period
+- Typically sample size: 30-40 samples for high-population controls (logs, tickets); 100% for low-population controls (annual training, quarterly reviews)
+- Walkthrough interviews for design verification
+- Tests of operating effectiveness for Type II assertion
+
+### Report (Months 11-12)
+
+The SOC 2 Type II report contains:
+
+- **Section 1:** Auditor's opinion (the page the customer reads first)
+- **Section 2:** Management assertion
+- **Section 3:** System description
+- **Section 4:** Trust services criteria + controls + test results + exceptions
+
+A "clean" opinion = unmodified opinion = no exceptions material to overall conclusion. Customer expects clean. Even one or two exceptions trigger customer questions.
+
+## Most Common SOC 2 Type II Exceptions
+
+Based on practitioner reports of common Type II exceptions:
+
+1. **Quarterly access review not completed for one quarter during observation period**
+2. **Vulnerability scan results not remediated within stated SLA on N of M samples**
+3. **Background check evidence missing for one or two employees hired during period**
+4. **Annual training not 100% complete by stated deadline** (someone always misses)
+5. **Change ticket without complete documentation** (testing evidence or approval missing)
+6. **Logging gap detected (e.g., 3 hours of missing logs on one date)**
+7. **Encryption configuration not validated** for one or two new resources spun up during period
+8. **Vendor security review not refreshed** during observation period for one or two critical vendors
+9. **Incident response not documented within stated SLA** for one or two minor incidents
+10. **Customer notification delayed past committed timeline** for one event
+
+**Strategy:** even one exception is OK if remediated and documented. The auditor cares about whether the exception is material — meaning the control "operates" in aggregate.
+
+## Type II vs Type I Discipline Delta
+
+| Aspect | Type I | Type II |
+|---|---|---|
+| Evidence required | Point-in-time | Continuous over observation period |
+| Sampling | Limited | Statistically meaningful samples per control |
+| Cost | Lower (months 1-3) | Higher (months 1-12) |
+| Customer trust | Limited | Strong |
+| Renewal | Build-once | Annual recurring |
+
+Most enterprise customers will not accept Type I beyond first year. Type I is a stepping-stone, not a steady state.
+
+## ISO 27001 ↔ SOC 2 Reuse
+
+The highest-leverage cross-framework pair. ~75% of ISO 27001:2022 Annex A controls map to SOC 2 TSC. Pattern:
+
+- If you have mature ISO 27001 → adding SOC 2 takes ~3 months incremental work
+- If you have mature SOC 2 → adding ISO 27001 takes ~3-6 months (ISO requires additional management-system formality: scope statement, internal audit programme, formal management review)
+
+Same controls; different formatting. See `compliance-os/references/cross_framework_overlap.md` for the merged-control catalogue.
+
+## Privacy TSC + GDPR Overlap
+
+If Privacy (P-series) is in scope:
+
+- P1.1 (Notice) ↔ GDPR Articles 13-14
+- P2.1 (Choice + consent) ↔ GDPR Article 7 + 8
+- P3.1 (Collection) ↔ GDPR Article 5 minimization
+- P4 (Use, retention, disposal) ↔ GDPR Article 5(1)(c)-(e)
+- P5 (Access) ↔ GDPR Article 15
+- P6.1 (Disclosure) ↔ GDPR Article 13/14 + DPA agreements
+- P7 (Quality) ↔ GDPR Article 5(1)(d)
+- P8 (Monitoring + enforcement) ↔ GDPR Article 24 (accountability)
+
+If both apply, build evidence to GDPR specification (which is more prescriptive) and report against SOC 2 TSC.
+
+## Cross-Framework Reuse
+
+SOC 2 audit work supports:
+
+- **ISO 27001** — primary cross-walk (~75% control reuse)
+- **PCI DSS** — overlap on access control, encryption, logging, vulnerability mgmt
+- **HITRUST** — overlap on security controls
+- **NIST CSF** — common control vocabulary
+
+Pair with `compliance-os/references/multi_framework_audit_playbook.md`.
+
+## When This Reference Doesn't Help
+
+- **SOC 1 (financial reporting controls)** — different scope; engage financial-audit-focused firm
+- **SOC 3 (general use report)** — different distribution rules; less common
+- **HITRUST CSF certification** — separate framework
+- **Vendor risk vs SOC 2 report consumption** — different perspective; downstream activity
+
+---
+
+**Source authorities (non-exhaustive):**
+
+- **AICPA AT-C 105 + AT-C 205** — Attestation engagement standards
+- **AICPA AU-C 240** — Auditor's responsibilities relating to fraud (conceptually applied)
+- **AICPA Trust Services Criteria (2017 + 2022 update)** — TSC text
+- **AICPA SOC 2 Reporting Guide** (continuously updated)
+- **ISACA CISA Review Manual** — IS audit methodology overlap
+- **PCAOB standards** — for audit-firm methodology context
+- **NIST SP 800-53A Rev 5** — for assessment procedure precedent
+- **ISO/IEC 27001:2022 + Annex A** — the primary cross-walk standard
+- **Industry retrospectives** — published reports from major audit firms (Big 4 + Schellman + Coalfire + A-LIGN) on common SOC 2 exceptions
+- **The Open Group + IIA** — internal audit methodology informing pre-engagement work

package/org-skills/soc2-compliance/references/trust_service_criteria.md

@@ -0,0 +1,273 @@
+# SOC 2 Trust Service Criteria Reference
+
+Comprehensive reference for all five AICPA Trust Service Criteria (TSC) categories. Each criterion includes its objective, sub-criteria, typical controls, and evidence examples.
+
+---
+
+## 1. Security (Common Criteria) — Required
+
+The Security category is mandatory for every SOC 2 engagement. It maps to the 17 COSO 2013 internal control principles organized into nine groups (CC1-CC9).
+
+### CC1 — Control Environment
+
+Establishes the foundation for all other components of internal control.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC1.1 | Demonstrate commitment to integrity and ethical values | Code of conduct, ethics hotline, background checks | Signed code of conduct, hotline reports, screening records |
+| CC1.2 | Board exercises oversight of internal control | Independent board/committee, regular reporting | Board meeting minutes, committee charters, oversight reports |
+| CC1.3 | Management establishes structure and reporting lines | Organizational charts, role definitions, RACI matrices | Org charts, job descriptions, authority matrices |
+| CC1.4 | Commitment to attract, develop, and retain competent individuals | Training programs, competency assessments, career development | Training completion records, skills assessments, HR policies |
+| CC1.5 | Hold individuals accountable for internal control responsibilities | Performance evaluations, disciplinary procedures | Performance review records, accountability documentation |
+
+### CC2 — Communication and Information
+
+Ensures relevant, quality information flows internally and externally.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC2.1 | Obtain and generate relevant quality information | Data classification, information quality standards | Classification policy, data quality reports |
+| CC2.2 | Internally communicate information and responsibilities | Internal newsletters, policy distribution, security awareness | Communication logs, training materials, acknowledgment records |
+| CC2.3 | Communicate with external parties | Customer notifications, vendor communications, incident notices | External communication policy, notification records, status pages |
+
+### CC3 — Risk Assessment
+
+Identifies and assesses risks that may prevent achievement of objectives.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC3.1 | Specify objectives to identify and assess risks | Risk management framework, risk appetite statement | Risk methodology document, risk appetite approval |
+| CC3.2 | Identify and analyze risks | Risk assessments, threat modeling, vulnerability analysis | Risk register, threat models, assessment reports |
+| CC3.3 | Consider potential for fraud | Fraud risk assessment, segregation of duties | Fraud risk report, SoD matrix, anti-fraud controls |
+| CC3.4 | Identify and assess changes impacting internal control | Change impact analysis, environmental scanning | Change assessments, business impact analyses |
+
+### CC4 — Monitoring Activities
+
+Ongoing evaluations to verify internal controls are present and functioning.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC4.1 | Select and perform ongoing and separate evaluations | Continuous monitoring, internal audits, control testing | Monitoring dashboards, audit reports, testing results |
+| CC4.2 | Evaluate and communicate deficiencies | Deficiency tracking, remediation management, management reporting | Deficiency logs, remediation plans, management reports |
+
+### CC5 — Control Activities
+
+Policies and procedures that ensure management directives are carried out.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC5.1 | Select and develop control activities that mitigate risks | Risk-based control selection, control design documentation | Control matrix, risk treatment plans |
+| CC5.2 | Select and develop technology controls | IT general controls, automated controls, technology governance | ITGC documentation, technology policies, automated control configs |
+| CC5.3 | Deploy control activities through policies and procedures | Policy library, procedure documentation, acknowledgment tracking | Policy repository, version history, signed acknowledgments |
+
+### CC6 — Logical and Physical Access Controls
+
+Restrict logical and physical access to information assets.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC6.1 | Logical access security over protected assets | IAM platform, SSO, MFA enforcement | IAM configuration, SSO settings, MFA enrollment reports |
+| CC6.2 | Access provisioning based on role and need | Role-based access, provisioning workflows, approval chains | Provisioning tickets, role matrix, approval records |
+| CC6.3 | Access removal on termination or role change | Offboarding checklists, automated deprovisioning | Deprovisioning tickets, termination checklists, access removal logs |
+| CC6.4 | Periodic access reviews | Quarterly user access reviews, entitlement validation | Access review reports, entitlement listings, sign-off records |
+| CC6.5 | Physical access restrictions | Badge systems, visitor management, secure areas | Badge access logs, visitor logs, physical access policies |
+| CC6.6 | Encryption of data in transit and at rest | TLS enforcement, disk encryption, key management | TLS configuration, encryption settings, key rotation records |
+| CC6.7 | Data transmission and movement restrictions | DLP tools, network segmentation, firewall rules | DLP configuration, network diagrams, firewall rule sets |
+| CC6.8 | Prevention/detection of unauthorized software | Endpoint protection, application whitelisting, malware scanning | EDR configuration, whitelist policies, scan reports |
+
+### CC7 — System Operations
+
+Detect and mitigate security events and anomalies.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC7.1 | Vulnerability identification and management | Vulnerability scanning, patch management, remediation SLAs | Scan reports, patch records, SLA compliance metrics |
+| CC7.2 | Monitor for anomalies and security events | SIEM, IDS/IPS, behavioral analytics | SIEM dashboards, alert rules, detection logs |
+| CC7.3 | Security event evaluation and classification | Incident classification criteria, triage procedures | Classification matrix, triage logs, escalation records |
+| CC7.4 | Incident response execution | Incident response plan, response team, communication procedures | IR plan, incident tickets, communication records |
+| CC7.5 | Incident recovery and lessons learned | Recovery procedures, post-incident reviews, plan updates | Recovery records, postmortem reports, plan revision history |
+
+### CC8 — Change Management
+
+Authorize, design, develop, test, and implement changes to infrastructure and software.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC8.1 | Change authorization, testing, and approval | Change management process, approval workflows, testing requirements | Change tickets, approval records, test results, deployment logs |
+
+### CC9 — Risk Mitigation
+
+Manage risks associated with business disruption, vendors, and partners.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| CC9.1 | Vendor and business partner risk management | Vendor assessment program, third-party risk management | Vendor risk assessments, vendor register, vendor SOC reports |
+| CC9.2 | Risk mitigation through transfer mechanisms | Cyber insurance, contractual protections | Insurance certificates, contract provisions |
+
+---
+
+## 2. Availability (A1) — Optional
+
+Addresses system uptime, performance, and recoverability commitments.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| A1.1 | Capacity and performance management | Auto-scaling, resource monitoring, capacity planning | Capacity dashboards, scaling policies, resource utilization trends |
+| A1.2 | Recovery operations | Backup procedures, DR planning, BCP documentation | Backup logs, DR plan, BCP documentation, recovery procedures |
+| A1.3 | Recovery testing | DR drills, failover tests, RTO/RPO validation | DR test reports, failover results, RTO/RPO measurements |
+
+### When to Include Availability
+
+- Your customers depend on your service uptime
+- You have SLAs with financial penalties for downtime
+- Your service is in the critical path of customer operations
+- You provide infrastructure or platform services
+
+### Key Metrics
+
+| Metric | Description | Typical Target |
+|--------|-------------|----------------|
+| RTO | Recovery Time Objective — max acceptable downtime | 1-4 hours |
+| RPO | Recovery Point Objective — max acceptable data loss | 1-24 hours |
+| SLA | Service Level Agreement — uptime commitment | 99.9%-99.99% |
+| MTTR | Mean Time to Recovery — average recovery duration | < 1 hour |
+
+---
+
+## 3. Confidentiality (C1) — Optional
+
+Protects information designated as confidential throughout its lifecycle.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| C1.1 | Identification of confidential information | Data classification scheme, confidential data inventory | Classification policy, data inventory, labeling standards |
+| C1.2 | Protection of confidential information | Encryption, access restrictions, DLP, secure transmission | Encryption configs, ACLs, DLP rules, secure transfer logs |
+| C1.3 | Disposal of confidential information | Secure deletion, media sanitization, retention enforcement | Disposal procedures, sanitization certificates, deletion logs |
+
+### When to Include Confidentiality
+
+- You handle trade secrets or proprietary business information
+- Contracts require confidentiality assurance
+- You process data classified above "public" in your classification scheme
+- Customers share confidential data for processing
+
+### Data Classification Levels
+
+| Level | Description | Handling Requirements |
+|-------|-------------|----------------------|
+| Public | No restrictions | No special controls |
+| Internal | Business use only | Access controls, basic encryption |
+| Confidential | Restricted access | Strong encryption, DLP, access reviews |
+| Highly Confidential | Strictly controlled | Strongest encryption, MFA, audit logging, need-to-know |
+
+---
+
+## 4. Processing Integrity (PI1) — Optional
+
+Ensures system processing is complete, valid, accurate, timely, and authorized.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| PI1.1 | Processing accuracy | Input validation, data integrity checks, output verification | Validation rules, integrity check logs, reconciliation reports |
+| PI1.2 | Processing completeness | Transaction monitoring, completeness checks, reconciliation | Transaction logs, batch processing reports, reconciliation records |
+| PI1.3 | Processing timeliness | SLA monitoring, batch job scheduling, processing alerts | SLA reports, job schedules, processing time metrics |
+| PI1.4 | Processing authorization | Authorization controls, segregation of duties, approval workflows | Authorization matrix, SoD analysis, approval records |
+
+### When to Include Processing Integrity
+
+- You perform financial calculations or transactions
+- Data accuracy is critical to customer operations
+- You provide analytics or reporting that drives business decisions
+- Regulatory requirements demand processing accuracy (e.g., healthcare, finance)
+
+### Validation Checkpoints
+
+| Stage | Validation | Method |
+|-------|-----------|--------|
+| Input | Data format, range, completeness | Automated validation rules |
+| Processing | Calculation accuracy, transformation correctness | Unit tests, reconciliation |
+| Output | Report accuracy, data completeness | Cross-checks, manual review, checksums |
+| Transfer | Transmission integrity, completeness | Hash verification, acknowledgment protocols |
+
+---
+
+## 5. Privacy (P1-P8) — Optional
+
+Governs the collection, use, retention, disclosure, and disposal of personal information. Closely aligns with GDPR, CCPA, and other privacy regulations.
+
+| Criterion | Objective | Typical Controls | Evidence |
+|-----------|-----------|-----------------|----------|
+| P1.1 | Notice — inform data subjects about data practices | Privacy policy, collection notices, purpose statements | Published privacy policy, collection banners, purpose documentation |
+| P2.1 | Choice and consent — provide opt-in/opt-out mechanisms | Consent management, preference centers, granular consent | Consent records, preference logs, opt-out mechanisms |
+| P3.1 | Collection — collect only necessary personal information | Data minimization, lawful basis documentation, purpose specification | Collection audits, lawful basis records, data flow diagrams |
+| P4.1 | Use, retention, and disposal — limit use and enforce retention | Purpose limitation, retention schedules, automated deletion | Use restriction controls, retention policies, deletion logs |
+| P4.2 | Disposal — secure disposal when no longer needed | Secure deletion, media sanitization | Disposal certificates, sanitization records |
+| P5.1 | Access — provide data subjects access to their data | DSAR processing, data portability, access portals | DSAR logs, response timelines, export capabilities |
+| P5.2 | Correction — allow data subjects to correct their data | Correction request processing, data update mechanisms | Correction logs, update records |
+| P6.1 | Disclosure — control third-party data sharing | Data sharing agreements, third-party inventory, DPAs | DPAs, sharing agreements, third-party register |
+| P6.2 | Notification — notify of breaches affecting personal data | Breach notification procedures, regulatory reporting | Breach response plan, notification records, reporting logs |
+| P7.1 | Quality — maintain accurate personal information | Data quality checks, accuracy verification, correction mechanisms | Quality reports, accuracy audits, correction records |
+| P8.1 | Monitoring — monitor privacy program effectiveness | Privacy audits, compliance reviews, complaint tracking | Audit reports, compliance dashboards, complaint logs |
+
+### When to Include Privacy
+
+- You process personal information (PII) of end users or customers
+- You operate in jurisdictions with privacy regulations (GDPR, CCPA, LGPD)
+- Customers request privacy assurance as part of vendor assessment
+- Your service involves health, financial, or other sensitive personal data
+
+### Privacy Criteria Overlap with GDPR
+
+| SOC 2 Privacy | GDPR Article | Alignment |
+|---------------|-------------|-----------|
+| P1 (Notice) | Art. 13-14 | Direct — transparency requirements |
+| P2 (Consent) | Art. 6-7 | Direct — lawful basis and consent |
+| P3 (Collection) | Art. 5(1)(b-c) | Direct — purpose limitation, minimization |
+| P4 (Retention) | Art. 5(1)(e) | Direct — storage limitation |
+| P5 (Access) | Art. 15-16 | Direct — data subject rights |
+| P6 (Disclosure) | Art. 33-34 | Direct — breach notification |
+| P7 (Quality) | Art. 5(1)(d) | Direct — accuracy principle |
+| P8 (Monitoring) | Art. 5(2) | Direct — accountability principle |
+
+---
+
+## TSC Selection Guide
+
+| Question | If Yes, Include |
+|----------|----------------|
+| Do you store/process customer data? | Security (required) |
+| Do customers depend on your uptime? | Availability |
+| Do you handle confidential business data? | Confidentiality |
+| Is data accuracy critical to your service? | Processing Integrity |
+| Do you process personal information? | Privacy |
+
+### Common Combinations
+
+| Company Type | Typical TSC Selection |
+|-------------|----------------------|
+| SaaS platform | Security + Availability |
+| Data analytics | Security + Processing Integrity + Confidentiality |
+| Healthcare SaaS | Security + Availability + Privacy + Confidentiality |
+| Financial services | Security + Availability + Processing Integrity + Confidentiality |
+| Infrastructure/PaaS | Security + Availability |
+| HR/Payroll SaaS | Security + Availability + Privacy |
+
+---
+
+## Mapping to Other Frameworks
+
+| SOC 2 Criteria | ISO 27001 | NIST CSF | HIPAA | PCI DSS |
+|---------------|-----------|----------|-------|---------|
+| CC1 (Control Environment) | A.5 (Policies) | ID.GV | Administrative Safeguards | Req 12 |
+| CC2 (Communication) | A.5.1 (Policies) | ID.GV | Administrative Safeguards | Req 12 |
+| CC3 (Risk Assessment) | A.8.2 (Risk) | ID.RA | Risk Analysis | Req 12.2 |
+| CC4 (Monitoring) | A.8.34 (Monitoring) | DE.CM | Audit Controls | Req 10 |
+| CC5 (Control Activities) | A.5-A.8 | PR | All Safeguards | Multiple |
+| CC6 (Logical/Physical Access) | A.5.15, A.7 | PR.AC | Access Controls | Req 7-9 |
+| CC7 (System Operations) | A.8.8, A.8.15 | DE, RS | Technical Safeguards | Req 5-6, 11 |
+| CC8 (Change Management) | A.8.32 | PR.IP | Change Management | Req 6.4 |
+| CC9 (Risk Mitigation) | A.5.19-5.22 | ID.SC | Business Associate Agreements | Req 12.8 |
+| A1 (Availability) | A.8.13-14 | PR.IP | Contingency Plan | Req 12.10 |
+| C1 (Confidentiality) | A.5.13-14, A.8.10-12 | PR.DS | Access Controls | Req 3-4 |
+| PI1 (Processing Integrity) | A.8.24-25 | PR.DS | Integrity Controls | Req 6.5 |
+| P1-P8 (Privacy) | A.5.34 (Privacy) | PR.PT | Privacy Rule | N/A |