bmad-plus 0.4.4 → 0.6.0

package/src/bmad-plus/packs/pack-shield/references/pci-compliance/pci-dss-v4-changes.md

@@ -0,0 +1,190 @@
+# PCI DSS v3.2.1 → v4.0 / v4.0.1 Change Guide
+
+Source: PCI DSS Summary of Changes v3.2.1 to v4.0 (PCI SSC); PCI DSS v4.0.1 (June 2024)
+
+---
+
+## Version Timeline
+
+| Version | Released | Status |
+|---------|----------|--------|
+| PCI DSS v3.2.1 | May 2018 | **Retired March 31, 2024** |
+| PCI DSS v4.0 | March 2022 | Superseded by v4.0.1 |
+| PCI DSS v4.0.1 | June 2024 | **Current** — minor errata update |
+
+**Important milestones:**
+- March 31, 2024: PCI DSS v3.2.1 retired — all assessments now use v4.0 or v4.0.1
+- March 31, 2025: All "future-dated" requirements from PCI DSS v4.0 became **mandatory** (previously best practice)
+- v4.0.1 corrects typographical errors and clarifications in v4.0; no new controls added
+
+---
+
+## Structural Changes
+
+| Aspect | v3.2.1 | v4.0 / v4.0.1 |
+|--------|--------|--------------|
+| Compliance approach | Defined approach only | Added **Customised Approach** |
+| Targeted Risk Analysis | Informal | **Formalised requirement** for flexible controls |
+| Requirements structure | 12 requirements, 259 sub-requirements | 12 requirements, 300+ sub-requirements |
+| Future-dated requirements | N/A | Requirements phased in by March 2025 |
+| Informative references | Embedded | Moved to PCI SSC Reference Tool (online) |
+| Focus | Prescriptive controls | Outcomes-focused (especially Customised Approach) |
+
+---
+
+## New Requirements in v4.0 (Mandatory from March 31, 2025)
+
+These requirements were "future-dated" in v4.0 (published March 2022 as best practice) and became mandatory on **March 31, 2025**:
+
+### Requirement 3: Protect Stored Account Data
+- **3.3.2**: SAD stored prior to authorisation is encrypted using strong cryptography (Applies to issuers and companies supporting issuing services only)
+- **3.3.3**: Encryption keys for pre-authorisation SAD are managed per key management requirements
+
+### Requirement 4: Protect CHD During Transmission
+- **4.2.1.1**: Inventory of trusted keys and certificates is maintained
+
+### Requirement 5: Anti-Malware
+- **5.3.3**: Anti-malware solution performs scans of removable electronic media
+- **5.4.1**: Automated technical solution to detect and protect against phishing attacks (**NEW concept**)
+
+### Requirement 6: Secure Development
+- **6.3.2**: Software inventory (SBOM) maintained for bespoke and custom software
+- **6.4.3**: All payment page scripts inventoried, authorised, and integrity protected (**NEW — critical for e-commerce**)
+
+### Requirement 7: Access Control
+- **7.2.4**: User accounts and access privileges reviewed at minimum every 6 months
+- **7.2.5**: Application/system accounts managed per policy
+- **7.2.5.1**: Privileges of application/system accounts reviewed at least every 6 months
+- **7.3.2**: Access control system configured to enforce least privilege
+
+### Requirement 8: Authentication
+- **8.3.6**: Passwords/passphrases for users without MFA changed at least every 90 days
+- **8.4.2**: MFA for all access into the CDE (**Extended scope — was only for remote access in v3.2.1**)
+- **8.6.1**: System/application accounts that can be used interactively managed and protected
+- **8.6.2**: Passwords/passphrases for system/application accounts not hardcoded in scripts or source code
+
+### Requirement 10: Logging
+- **10.4.1.1**: Automated log review mechanisms used (**NEW — manual-only review no longer sufficient**)
+- **10.7.2**: Failures of critical security controls detected, reported, and addressed promptly (**NEW**)
+- **10.7.3**: Failures of critical security controls responded to within defined timeframes
+
+### Requirement 11: Security Testing
+- **11.4.7**: Multi-tenant service providers support customers' requests for penetration testing
+- **11.6.1**: Change and tamper detection mechanism for HTTP headers and scripts on payment pages deployed (**NEW — critical for web skimming prevention**)
+
+### Requirement 12: Policy and Programs
+- **12.3.2**: Targeted risk analysis for each PCI DSS requirement that has a customised approach
+- **12.3.3**: Cryptographic cipher suites and protocols reviewed at least every 12 months
+- **12.3.4**: Hardware and software technologies reviewed at least every 12 months
+- **12.5.2.1**: PCI DSS scope verified by multi-tenant service providers at minimum every 6 months
+- **12.8.4**: TPSP compliance status monitored at least every 12 months
+- **12.9.2**: TPSPs support customers' requests for confirmation of PCI DSS responsibility
+- **12.10.4.1**: IR personnel training at minimum every 12 months
+- **12.10.7**: IR procedures for discovery of stored PAN in unexpected location
+
+---
+
+## Key Conceptual Changes
+
+### 1. Customised Approach (Major v4.0 Innovation)
+The Customised Approach allows organisations to implement alternative controls designed by the entity to achieve the stated **Objective** of a PCI DSS requirement, rather than following the prescriptive testing procedure.
+
+**Requirements for Customised Approach:**
+- A Targeted Risk Analysis (TRA) must be performed and documented for each customised control
+- TRA must be approved by senior management
+- Customised control must be assessed by a QSA using a Customised Approach Test Plan (CATP)
+- Annual review and revalidation required
+- Not available for SAQ A or SAQ B; typically used in ROC environments
+
+**When to use**: When the defined approach does not fit the technology architecture (e.g., cloud-native, microservices, zero-trust) and the organisation can demonstrably achieve the security objective through alternative means.
+
+### 2. Expanded MFA Requirement (Req 8.4.2)
+In v3.2.1, MFA was required for:
+- All non-console administrative access to the CDE
+- Remote access to the network from outside the entity's network
+
+In v4.0, MFA is required for **ALL access into the CDE** — including access from within the internal network. This is the most impactful change for many organisations and a common gap.
+
+**Practical impact**: If a user on the internal corporate LAN accesses a CDE system, MFA is now required. VPN + network segmentation alone is no longer sufficient.
+
+### 3. Payment Page Script Security (Req 6.4.3 and 11.6.1)
+These requirements address **web skimming** (e.g., Magecart attacks) where malicious scripts are injected into payment pages to steal cardholder data.
+
+**Req 6.4.3**: All scripts loaded and executed in the consumer's browser on a payment page must be:
+- Inventoried with a method to confirm integrity
+- Authorised by management — documented justification for each script
+- Integrity protected — either using CSP (Content Security Policy), SRI (Sub-Resource Integrity), or equivalent
+
+**Req 11.6.1**: A change and tamper detection mechanism must be deployed that:
+- Alerts personnel to unauthorised modification of HTTP headers and content of payment pages
+- Is assessed at minimum every 7 days (or frequency defined by targeted risk analysis)
+
+### 4. Phishing Protection (Req 5.4.1)
+Organisations must now implement automated technical solutions to detect and protect users against phishing attacks. Acceptable solutions include:
+- Email security gateways with anti-phishing/URL scanning
+- DNS filtering solutions
+- DMARC + DKIM + SPF email authentication
+- Anti-phishing browser extensions managed by policy
+
+### 5. Targeted Risk Analysis (TRA)
+The TRA is a formalised risk analysis process used to:
+- Define controls for requirements with flexible frequencies (e.g., how often to review certain items)
+- Justify Customised Approach implementations
+- Document risk-based decisions
+
+Required TRA elements: Risk description | Defined approach requirement | Reason for customisation | How the objective is achieved | Evidence of effectiveness | Management sign-off | Annual review date
+
+### 6. Automated Log Review (Req 10.4.1.1)
+Manual daily log review is no longer sufficient. An automated mechanism (e.g., SIEM with alert rules, automated anomaly detection) must be in place. The automated system must alert on anomalous activity.
+
+---
+
+## Requirements Removed or Significantly Changed
+
+| v3.2.1 Requirement | Change in v4.0 |
+|-------------------|---------------|
+| Req 6.3 (Application vulnerabilities) | Restructured into 6.3.1–6.5.6 |
+| Req 10.6 (Log review) | Restructured into 10.4 with automated review added |
+| Req 11.2 (Vulnerability scans) | Restructured; ASV scan requirements unchanged |
+| Req 12.10 (IR plan) | Expanded with new sub-requirements |
+| Business-as-usual (BAU) activities | Replaced by more specific ongoing compliance requirements |
+| Appendix A2 (TLS migration) | Removed — TLS 1.0/1.1 migration deadline passed |
+| Appendix A3 (Designated Entities) | Moved/updated |
+
+---
+
+## Migration Checklist: v3.2.1 → v4.0.1
+
+**Governance and Policy (Req 12)**
+- [ ] Establish a formal Targeted Risk Analysis (TRA) process and template (12.3.2)
+- [ ] Conduct annual review of cryptographic cipher suites (12.3.3)
+- [ ] Conduct annual hardware/software technology lifecycle review (12.3.4)
+- [ ] Confirm TPSP compliance status annually — update TPSP register (12.8.4)
+- [ ] Train IR personnel at minimum annually (12.10.4.1)
+- [ ] Create IR procedure for unexpected PAN discovery (12.10.7)
+- [ ] Verify PCI DSS scope at least every 12 months and after major changes (12.5.2)
+
+**Authentication (Req 8)**
+- [ ] Extend MFA to ALL access into the CDE — including internal network users (8.4.2)
+- [ ] Update password policy: minimum 12 characters (8.3.5)
+- [ ] Ensure no hardcoded passwords in scripts or source code (8.6.2)
+
+**E-commerce and Web Application (Req 6, 11)**
+- [ ] Create inventory of all payment page scripts with authorisation and integrity controls (6.4.3)
+- [ ] Deploy change/tamper detection on HTTP headers and payment page content (11.6.1)
+- [ ] Enable CSP/SRI headers or equivalent script integrity controls
+
+**Anti-Malware and Phishing (Req 5)**
+- [ ] Deploy automated anti-phishing technical solution (5.4.1): email gateway + SPF/DKIM/DMARC
+- [ ] Add removable media scanning to anti-malware coverage (5.3.3)
+
+**Logging (Req 10)**
+- [ ] Implement automated log review mechanism (SIEM or equivalent) (10.4.1.1)
+- [ ] Configure monitoring for critical security control failures (10.7.2)
+
+**Access Control (Req 7, 8)**
+- [ ] Implement 6-monthly access reviews for all accounts (7.2.4)
+- [ ] Document and control all application/system account access (7.2.5)
+
+**Software Inventory (Req 6)**
+- [ ] Build and maintain Software Bill of Materials (SBOM) for bespoke software (6.3.2)

package/src/bmad-plus/packs/pack-shield/references/section-508/wcag-mapping.md

@@ -0,0 +1,160 @@
+# Section 508 / WCAG 2.0 AA — Detailed Reference
+
+## Section 508 Provision Map
+
+| 508 Provision | Scope | WCAG Equivalent |
+|---------------|-------|-----------------|
+| E205.2 | Web content | WCAG 2.0 Level A and AA |
+| E205.3 | Electronic documents | WCAG 2.0 Level A and AA (as applicable) |
+| E205.4 | Software (user interface) | WCAG 2.0 Level A and AA |
+| E204 | Authoring tools | WCAG 2.0 Level A and AA |
+| Chapter 3 | Functional Performance Criteria | Without visual, colour, hearing, speech, fine motor, cognitive limitations |
+| Chapter 4 | Hardware | Physical ICT accessible controls, display, clearance |
+| Chapter 6 | Support docs and services | Documentation and help in accessible formats |
+
+---
+
+## WCAG 2.0 Level A Success Criteria — Common Failures
+
+### 1.1.1 Non-text Content
+- **Failure:** `<img>` missing `alt` attribute, or `alt=""` on informative image
+- **Failure:** Icon buttons with no accessible name (`aria-label` or `aria-labelledby`)
+- **Failure:** Charts and graphs with no text alternative describing data
+- **Testing:** Automated (axe, WAVE) + manual screen reader review
+- **Fix:** Add meaningful `alt` text; use `alt=""` only for decorative images; use `aria-label` on icon-only buttons
+
+### 1.3.1 Info and Relationships
+- **Failure:** Visual headings not marked up with `<h1>`–`<h6>` (styled `<div>` or `<span>` used instead)
+- **Failure:** Data tables with no `<th>` or `scope` attributes
+- **Failure:** Form fields with visual label not programmatically associated (missing `<label for="">` or `aria-labelledby`)
+- **Failure:** Required fields indicated only by colour or asterisk with no screen-reader-accessible text
+- **Testing:** DOM inspection, NVDA/JAWS, automated (partial)
+- **Fix:** Semantic HTML first; `aria-*` attributes only when semantic HTML insufficient
+
+### 2.1.1 Keyboard
+- **Failure:** Custom dropdowns, date pickers, modal dialogs not operable by keyboard
+- **Failure:** Mouse-only event handlers (`onclick` on non-interactive elements, `mouseover` without `focus` equivalent)
+- **Failure:** Drag-and-drop with no keyboard alternative
+- **Failure:** Keyboard trap in modal — Tab cycles only within modal but no way to close it
+- **Testing:** Tab through entire page; activate all controls; open/close modals
+- **Fix:** Use native HTML controls where possible; for custom widgets, implement ARIA keyboard patterns (ARIA Authoring Practices Guide)
+
+### 1.4.1 Use of Colour
+- **Failure:** Form validation errors shown only by red border with no text or icon
+- **Failure:** Required field indicator is colour-only (red asterisk with no "required" text)
+- **Failure:** Link text colour is the only differentiator from surrounding body text (no underline or other visual cue)
+
+### 4.1.2 Name, Role, Value
+- **Failure:** Custom checkboxes/radio buttons styled with CSS, no ARIA role or checked state
+- **Failure:** Tab panels with no `role="tab"`, `role="tablist"`, `aria-selected`
+- **Failure:** Toggle buttons with no `aria-pressed` attribute
+- **Failure:** Expanded/collapsed accordions with no `aria-expanded`
+- **Testing:** Inspect ARIA properties in browser accessibility tree; test with NVDA/JAWS
+- **Fix:** Follow WAI-ARIA Authoring Practices Guide patterns for each widget type
+
+---
+
+## WCAG 2.0 Level AA Success Criteria — Common Failures
+
+### 1.4.3 Contrast (Minimum)
+- Normal text (< 18pt or < 14pt bold): **4.5:1** minimum contrast ratio against background
+- Large text (≥ 18pt or ≥ 14pt bold): **3:1** minimum
+- **Failure:** Light grey text on white background (e.g., #767676 on #FFFFFF = 4.48:1 — fails AA)
+- **Failure:** Placeholder text in input fields (often fails; placeholder is not a label substitute)
+- **Exception:** Text in logos, inactive UI components, decorative text
+- **Tool:** WebAIM Contrast Checker, Colour Contrast Analyser (desktop app), browser DevTools
+
+### 1.4.4 Resize Text
+- **Failure:** Text rendered in `px` units inside CSS `@media` queries that prevent browser zoom from scaling text
+- **Failure:** Fixed-height containers that clip text when zoomed to 200%
+- **Fix:** Use relative units (`rem`, `em`) for font sizes and container heights; test at 200% browser zoom
+
+### 2.4.5 Multiple Ways
+- **Requirement:** Provide at least two ways to find content: search + navigation, OR sitemap + navigation
+- **Exception:** Pages that are the result of a process (e.g., checkout confirmation page) are excluded
+
+### 2.4.7 Focus Visible
+- **Failure:** CSS `outline: none` or `outline: 0` removing the default focus ring with no replacement
+- **Failure:** Focus ring present but invisible against background colour
+- **Fix:** Never remove focus styling without replacing it; use `focus-visible` CSS pseudo-class
+
+### 3.3.3 Error Suggestion
+- **Failure:** Form validation says "invalid input" without specifying what is wrong or how to fix it
+- **Fix:** "Please enter a date in MM/DD/YYYY format" — specific, actionable suggestion
+
+### 3.3.4 Error Prevention
+- **Requirement:** For legal, financial, or data deletion transactions: provide a review-and-confirm step, OR allow the submission to be reversed/cancelled
+
+---
+
+## Functional Performance Criteria (Chapter 3) — Section 508
+
+| Criterion | Requirement |
+|-----------|-------------|
+| 302.1 Without Vision | At least one mode operable without vision (screen reader support) |
+| 302.2 With Limited Vision | At least one mode with features that accommodate limited vision (zoom, high contrast) |
+| 302.3 Without Perception of Colour | Colour not the only means to convey information |
+| 302.4 Without Hearing | At least one mode operable without hearing (captions, transcripts, visual alerts) |
+| 302.5 With Limited Hearing | At least one mode with features for limited hearing (volume control, captioning) |
+| 302.6 Without Speech | At least one mode operable without speech |
+| 302.7 With Limited Manipulation | At least one mode operable without fine motor control (no simultaneous key presses, no timed actions) |
+| 302.8 With Limited Reach and Strength | At least one mode for limited reach (reachable controls) |
+| 302.9 With Limited Language, Cognitive, and Learning | At least one mode that accommodates limited cognitive ability |
+
+---
+
+## Assistive Technology Testing Matrix
+
+| AT + Browser | Primary Use Case | Notes |
+|--------------|-----------------|-------|
+| JAWS + Chrome | Federal agency standard; most common screen reader in US gov | Test all interactive widgets, form flows, dynamic content (ARIA live regions) |
+| NVDA + Chrome or Firefox | Open-source; widely used for testing; required for VPAT testing | Free; good for broad coverage |
+| VoiceOver + Safari (macOS) | Mac users; required if product targets Mac/iOS | Keyboard shortcut: Cmd+F5 |
+| VoiceOver + Safari (iOS) | Mobile web and native iOS apps | Swipe navigation; activate with triple-click Home/Side button |
+| TalkBack + Chrome (Android) | Android web and native apps | Swipe navigation; activate in Accessibility settings |
+| Dragon NaturallySpeaking | Voice control users | Test all link text and button labels are speakable |
+| Keyboard only | Most impactful test; catches most 2.1.x failures | Tab, Shift-Tab, Enter, Space, Arrow keys |
+| High Contrast Mode (Windows) | OS-level contrast override | Ensure no information lost; images must not disappear |
+| Browser Zoom 200% | SC 1.4.4 | Check for horizontal scroll, content overlap, clipped text |
+| ZoomText / Magnifier | Low-vision users | Test with 4x magnification |
+
+---
+
+## PDF Accessibility Checklist
+
+| Requirement | How to Verify | Tool |
+|-------------|---------------|------|
+| Document is tagged | File → Properties → Description tab: "Tagged PDF: Yes" | Acrobat Pro |
+| Tag tree structure correct | Accessibility → Reading Order; Tags panel | Acrobat Pro |
+| Reading order = visual order | View → Read Out Loud; or Articles panel | Acrobat Pro |
+| Images have Alt text | Right-click image tag → Properties → Alternate Text | Acrobat Pro |
+| Form fields have Tooltip/name | Open Form Editor; check Tooltip field for each control | Acrobat Pro |
+| Table tags with TH/Scope | Tags panel; Table Inspector | Acrobat Pro |
+| Document language set | File → Properties → Advanced → Reading Options | Acrobat Pro |
+| Document title set | File → Properties → Description → Title | Acrobat Pro |
+| No flicker/motion (if any) | Review any embedded multimedia | Manual |
+| Passes automated check | Accessibility → Full Check → Run | Acrobat Pro |
+
+---
+
+## Common Procurement Deficiencies in VPATs
+
+1. **Outdated template** — using VPAT 1.x instead of VPAT 2.x (WCAG Edition). Reject and require resubmission.
+2. **"Supports" without evidence** — vendor claims support with no remarks. Require explanation for each "Supports" claim.
+3. **"Not Applicable" overuse** — vendor marks criteria N/A without justification. Challenge: almost no product has 100% N/A for interactive criteria.
+4. **Missing functional performance criteria** — vendors skip Chapter 3 entirely. Required for all ICT.
+5. **No testing methodology disclosed** — VPAT must state how testing was conducted (automated tools, AT + browser combinations, dates).
+6. **Version mismatch** — VPAT covers version 1.0 but agency is procuring version 2.0. Require VPAT for the exact version being procured.
+
+---
+
+## Key Legal References
+
+- **29 U.S.C. § 794d** — Section 508 statutory text
+- **36 CFR Part 1194** — Access Board's Revised Section 508 Standards (effective 18 January 2018)
+- **FAR Subpart 39.2** — Federal Acquisition Regulation provisions on Section 508
+- **FAR clause 52.239-2** — Section 508 contract clause (mandatory for ICT procurement)
+- **OMB Memorandum M-24-08** — "Strengthening Digital Accessibility and the Management of Section 508 of the Rehabilitation Act" (January 2024)
+- **Section508.gov** — GSA's official guidance, VPAT templates, testing resources
+- **WCAG 2.0** — W3C Recommendation (11 December 2008) — the incorporated technical standard
+- **WCAG 2.1** — W3C Recommendation (5 June 2018) — supersedes 2.0; additional mobile/cognitive criteria (not yet mandated by 508 but recommended)

package/src/bmad-plus/packs/pack-shield/references/soc2/controls.md

@@ -0,0 +1,241 @@
+# SOC 2 Control Matrix Reference
+
+## Table of Contents
+1. [Security — Common Criteria (CC1–CC9)](#security--common-criteria)
+2. [Availability (A1)](#availability-a1)
+3. [Confidentiality (C1)](#confidentiality-c1)
+4. [Processing Integrity (PI1)](#processing-integrity-pi1)
+5. [Privacy (P1–P8)](#privacy-p1p8)
+6. [Control Statement Template](#control-statement-template)
+
+---
+
+## Security — Common Criteria
+
+### CC1 — Control Environment
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC1.1 | COSO principles demonstrated; commitment to integrity and ethical values | No code of conduct or ethics policy; leadership not visibly engaged |
+| CC1.2 | Board or equivalent oversight of security program | No documented board/executive security oversight; no meeting minutes |
+| CC1.3 | Org structure, reporting lines, authorities defined | Org chart not current; security roles undefined |
+| CC1.4 | Competent personnel; HR lifecycle controls | No background checks; no security training program |
+| CC1.5 | Accountability for security responsibilities | Performance goals don't include security; no enforcement |
+
+**Example control (CC1.4):**
+```
+Control ID:    CC1.4-001
+Title:         Security Awareness Training
+Type:          Preventive
+Owner:         HR / Security
+Frequency:     Annual (+ onboarding)
+Description:   All employees complete annual security awareness training covering
+               phishing, data handling, and incident reporting. Completion is tracked
+               and non-completions escalated to managers.
+Evidence:      Training completion report from LMS, onboarding checklist sign-offs
+Test:          Inspect training platform report; confirm >95% completion within period;
+               sample 5 employees to verify completion dates within 12 months.
+```
+
+---
+
+### CC2 — Communication and Information
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC2.1 | Quality information available to support control objectives | Policies inaccessible or not distributed; no intranet/wiki |
+| CC2.2 | Internal communication about security responsibilities | Security updates not communicated; no all-hands or newsletter |
+| CC2.3 | External communication with customers, regulators, vendors | No process to notify customers of security incidents; SLA terms vague |
+
+---
+
+### CC3 — Risk Assessment
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC3.1 | Defined risk objectives; risk tolerance stated | No written risk appetite or tolerance statement |
+| CC3.2 | Risk identification and analysis process | No formal risk assessment; informal or ad hoc only |
+| CC3.3 | Fraud risk considered | No fraud risk assessment or controls |
+| CC3.4 | Technology change risks assessed | Changes don't trigger risk reassessment |
+
+**Example control (CC3.2):**
+```
+Control ID:    CC3.2-001
+Title:         Annual Risk Assessment
+Type:          Detective
+Owner:         CISO / Security Manager
+Frequency:     Annual + event-driven
+Description:   A formal risk assessment is performed annually, identifying threats,
+               vulnerabilities, and likelihood/impact ratings. A risk register is
+               maintained and reviewed quarterly by the security committee.
+Evidence:      Risk register (dated), risk assessment report with sign-off,
+               security committee meeting minutes
+Test:          Inspect risk register; confirm dated within 12 months; verify
+               management sign-off; confirm high risks have remediation owners.
+```
+
+---
+
+### CC4 — Monitoring Controls
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC4.1 | Ongoing and separate evaluations of controls | No internal audits; no continuous monitoring program |
+| CC4.2 | Deficiencies evaluated and communicated | No deficiency tracking; findings not escalated |
+
+---
+
+### CC5 — Control Activities
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC5.1 | Controls selected to mitigate risks | Controls not mapped to risks; no controls matrix |
+| CC5.2 | Technology controls deployed | No MFA, no endpoint protection, no SIEM |
+| CC5.3 | Policies and procedures deployed | Policies exist but not enforced; no procedures for key processes |
+
+---
+
+### CC6 — Logical and Physical Access Controls
+
+This is typically the most heavily tested area.
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC6.1 | Logical access security measures | No MFA on critical systems; no SSO; shared accounts |
+| CC6.2 | New access provisioning authorized | No formal access request/approval process |
+| CC6.3 | Termination / role change access removal | Terminated employees not promptly de-provisioned (>24hr is a flag) |
+| CC6.4 | Access credentials protected | Passwords stored in plaintext; no PAM for privileged accounts |
+| CC6.5 | Logical access reviewed | No periodic user access reviews (quarterly/annual) |
+| CC6.6 | Logical access restricted from threats | No IDS/IPS; no network segmentation |
+| CC6.7 | Data transmission protected | Unencrypted data in transit; no TLS enforcement |
+| CC6.8 | Unauthorized software prevented | No application whitelisting or MDM; shadow IT uncontrolled |
+
+**Example control (CC6.3):**
+```
+Control ID:    CC6.3-001
+Title:         Access Termination — Employee Offboarding
+Type:          Preventive
+Owner:         IT / HR
+Frequency:     Event-driven (each termination)
+Description:   Upon employee termination, IT disables all system access within 24 hours
+               of the HR-initiated offboarding ticket. A checklist confirms: AD account
+               disabled, SaaS app access revoked, VPN certificate revoked, hardware
+               returned. HR confirms completion in the HRIS.
+Evidence:      Offboarding tickets, access revocation logs, HRIS termination records
+Test:          Select sample of 10–25 terminations in audit period; verify access was
+               revoked within 24 hours using AD logs and ticket timestamps.
+```
+
+---
+
+### CC7 — System Operations
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC7.1 | Vulnerability and malware detection | No vulnerability scanning; no EDR on endpoints |
+| CC7.2 | Monitoring for security events | No SIEM or log aggregation; alerts not reviewed |
+| CC7.3 | Security incidents evaluated and responded to | No incident response plan; incidents not documented |
+| CC7.4 | Security incidents contained and resolved | No IR runbook; no post-incident review process |
+| CC7.5 | Identified vulnerabilities remediated | No SLA for patching critical vulns; no patch cadence |
+
+---
+
+### CC8 — Change Management
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC8.1 | Authorized, tested, and approved changes | Changes deployed without tickets or approval; no testing in staging |
+
+**Example control (CC8.1):**
+```
+Control ID:    CC8.1-001
+Title:         Production Change Approval
+Type:          Preventive
+Owner:         Engineering / DevOps
+Frequency:     Event-driven
+Description:   All production changes require a change request ticket approved by
+               an authorized reviewer (tech lead or manager) before deployment.
+               Emergency changes require retroactive approval within 24 hours.
+               Changes are tested in staging/QA before production promotion.
+Evidence:      Change tickets with approvals, deployment logs, PR approvals in
+               version control (GitHub/GitLab), JIRA/Linear ticket history
+Test:          Sample 20–30 changes in audit period; verify each has prior
+               approval, tester other than developer, and ticket closure with
+               deployment confirmation.
+```
+
+---
+
+### CC9 — Risk Mitigation
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| CC9.1 | Business disruption risk mitigation | No BCP; BCP untested |
+| CC9.2 | Vendor and business partner risk managed | No vendor inventory; no vendor assessments performed |
+
+---
+
+## Availability (A1)
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| A1.1 | Capacity monitored and managed | No capacity monitoring; no alerting on resource thresholds |
+| A1.2 | Environmental threats managed; backups tested | No backup verification; no restore testing |
+| A1.3 | Recovery tested; RTO/RPO defined | RTO/RPO not defined; no DR test records |
+
+---
+
+## Confidentiality (C1)
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| C1.1 | Confidential information identified and protected | No data classification; no data inventory |
+| C1.2 | Confidential information disposed of appropriately | No data retention/disposal policy; no certificate of destruction |
+
+---
+
+## Processing Integrity (PI1)
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| PI1.1 | Processing complete, valid, accurate, timely, authorized | No input/output validation; no reconciliation controls |
+| PI1.2 | System inputs authorized | No authorization checks; no separation of duties |
+| PI1.3 | System outputs complete and accurate | No output verification or reconciliation |
+| PI1.4 | Processing errors detected and corrected | No error handling or alerting; errors silently discarded |
+| PI1.5 | Stored items protected | No integrity monitoring; no checksums |
+
+---
+
+## Privacy (P1–P8)
+
+| Criterion | What auditors look for | Common gap |
+|---|---|---|
+| P1 | Privacy notice provided to individuals | No privacy notice; notice doesn't match actual practices |
+| P2 | Choice and consent obtained | No consent mechanism; opt-out not honored |
+| P3 | Personal information collected only as stated | Collecting more data than disclosed; no data minimization |
+| P4 | Personal information used only as stated | Using PII for undisclosed purposes |
+| P5 | Personal information retained and disposed per policy | No retention schedule; PII kept indefinitely |
+| P6 | Personal information disclosed only as authorized | No data sharing agreements; unauthorized third-party access |
+| P7 | Personal information quality maintained | No process to update/correct inaccurate data |
+| P8 | Privacy complaints and inquiries handled | No DSR (Data Subject Request) process; no privacy contact |
+
+---
+
+## Control Statement Template
+
+```
+Control ID:    [TSC-criterion-sequence, e.g., CC6.1-002]
+TSC Criterion: [e.g., CC6.1 – Logical Access Security Measures]
+Control Title: [Short descriptive name]
+Control Type:  [Preventive | Detective | Corrective]
+Control Owner: [Role/team]
+Frequency:     [Continuous | Daily | Weekly | Monthly | Quarterly | Annual | Event-driven]
+Description:   [What the control does, who performs it, how it works, and what
+               systems/processes are covered. 2–5 sentences.]
+Evidence:      [Artifacts produced by this control that prove it operates:
+               logs, reports, tickets, sign-offs, screenshots, exports.]
+Test Procedure:[How an auditor would test this: sample size, data sources,
+               pass/fail criteria. Match Type 1 (design) vs Type 2 (operating).]
+Related Policies: [Which policy governs this control]
+Linked Risks:  [Which risks from risk register this control mitigates]
+```