bmad-plus 0.4.4 → 0.6.0

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

@@ -0,0 +1,236 @@
+# SOC 2 Audit Evidence Reference
+
+## Table of Contents
+1. [Evidence Fundamentals](#evidence-fundamentals)
+2. [Evidence by Criterion](#evidence-by-criterion)
+3. [Evidence Quality Checklist](#evidence-quality-checklist)
+4. [Common Evidence Pitfalls](#common-evidence-pitfalls)
+
+---
+
+## Evidence Fundamentals
+
+### Type 1 vs Type 2 Evidence
+
+| | Type 1 | Type 2 |
+|---|---|---|
+| **What's tested** | Control design at a point in time | Control operating effectiveness over a period |
+| **Evidence needed** | Proof control *exists* and is *designed* correctly | Proof control *operated consistently* throughout the period |
+| **Sampling** | Single instance is usually sufficient | Auditor will sample multiple instances across the period |
+| **Typical audit period** | A date (e.g., Dec 31, 2024) | 6–12 months (e.g., Jan 1 – Dec 31, 2024) |
+
+For Type 2, auditors typically use **statistical sampling** — for higher-frequency controls (daily logs, weekly scans), they'll pull samples from across the period. For lower-frequency controls (annual risk assessment, quarterly access reviews), they'll test every instance.
+
+### Sampling Guidance by Control Frequency
+
+| Frequency | Auditor sample size (typical) |
+|---|---|
+| Continuous / daily | 20–30 items from across the period |
+| Weekly | 5–10 weeks sampled |
+| Monthly | 3–6 months sampled |
+| Quarterly | All 4 quarters |
+| Annual | 1 (but must cover the audit period) |
+| Event-driven (e.g., per hire/termination) | 20–30 events or 100% if fewer than 20 |
+
+---
+
+## Evidence by Criterion
+
+### CC1 — Control Environment
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Organizational chart (current) | Org structure and reporting lines | PDF / org tool export |
+| Code of Conduct / Ethics policy | Commitment to integrity | Signed policy doc |
+| Security awareness training completion report | CC1.4 — competent personnel | LMS export with timestamps |
+| Board/executive security meeting minutes | Leadership oversight | Meeting minutes PDF |
+| Background check records | CC1.4 — personnel screening | HRIS confirmation (redacted) |
+| Security committee charter | Governance structure | Document |
+
+---
+
+### CC2 — Communication and Information
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Policy distribution records | Policies communicated to employees | Email screenshots, intranet access logs |
+| Employee policy acknowledgment log | Personnel aware of requirements | Signed acknowledgments or LMS completion |
+| Customer-facing security communications (e.g., SLA, security page) | External communication | URL / screenshot with date |
+| Incident notification records (if any occurred) | CC2.3 — external notification process | Email/ticket records |
+
+---
+
+### CC3 — Risk Assessment
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Risk register (dated, with owners) | Risks identified and tracked | Spreadsheet / GRC tool export |
+| Risk assessment report with management sign-off | Formal annual process completed | PDF with signatures and date |
+| Security committee meeting minutes (risk review) | Ongoing risk oversight | Minutes |
+| Risk treatment decisions (accept/mitigate/transfer) | Risks actively managed | Risk register or separate log |
+
+---
+
+### CC4 — Monitoring Controls
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Internal audit reports | Self-evaluation of controls | Audit report PDF |
+| Control deficiency log / tracking | Deficiencies identified and remediated | Spreadsheet or ticket system |
+| Executive/board security reporting | Control performance communicated upward | Dashboard screenshots, board slides |
+
+---
+
+### CC5 — Control Activities
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Controls matrix (policies mapped to risks) | Controls selected to address risks | Spreadsheet |
+| MFA enrollment reports | Technology controls deployed | Okta/Azure AD report |
+| Endpoint protection deployment report | CC5.2 — technology controls | MDM / EDR console export |
+| Firewall rule review records | Network controls reviewed | Firewall config review document |
+
+---
+
+### CC6 — Logical and Physical Access Controls
+
+This criterion typically generates the most evidence requests.
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| User access list (production systems, AWS, GitHub, SaaS) | Current state of access | Console exports |
+| Access request/approval tickets | CC6.2 — provisioning authorized | JIRA / ServiceNow tickets |
+| Termination access revocation records | CC6.3 — timely de-provisioning | HR ticket + AD/system logs |
+| Access review sign-offs (quarterly/annual) | CC6.5 — reviews performed | Spreadsheet with reviewer signature and date |
+| MFA configuration screenshots | CC6.1 — credentials protected | Admin console screenshots |
+| Privileged access list and reviews | CC6.4, CC6.5 — admin access controlled | Export with review sign-off |
+| Encryption-in-transit configuration | CC6.7 — data protected | SSL cert details, config screenshots |
+| Physical access records (if applicable) | CC6 — physical controls | Keycard logs, visitor logs, office photos |
+
+**Access review evidence tips:**
+- Export must be dated and show reviewer name
+- Bulk "no change" reviews are a flag — show evidence of actual review decisions
+- Entitlement changes made as a result of review should be evidenced (tickets)
+
+---
+
+### CC7 — System Operations
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Vulnerability scan reports (quarterly or more frequent) | CC7.1 — vulnerabilities detected | Scan tool export (Qualys, Tenable, etc.) |
+| Penetration test report + remediation tracking | CC7.1 — testing performed | Pentest report PDF + remediation tickets |
+| SIEM alerts / security event dashboard | CC7.2 — monitoring in place | Dashboard screenshot (dated) |
+| Incident tickets (all incidents in period) | CC7.3, CC7.4 — incidents managed | Ticket system export |
+| Incident post-mortems / lessons learned | CC7.4 — resolution documented | Post-mortem documents |
+| Patch management reports (before/after) | CC7.5 — vulnerabilities remediated | Patch report with dates |
+| IR tabletop exercise records | CC7.3 — IR plan tested | Exercise agenda, attendance, findings |
+| Antivirus/EDR status reports | CC7.1 — malware detection | Console export |
+
+---
+
+### CC8 — Change Management
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Change tickets with approvals (sample across period) | Changes authorized before deployment | JIRA / Linear / ServiceNow tickets |
+| PR/merge request approvals in version control | Code review and approval | GitHub/GitLab PR screenshots |
+| Deployment logs | Changes deployed as approved | CI/CD pipeline logs |
+| Change advisory board (CAB) meeting minutes | High-risk changes reviewed | Meeting notes |
+| Emergency change approvals and retroactive sign-offs | Emergency process followed | Ticket records |
+
+---
+
+### CC9 — Vendor Risk
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Vendor inventory (tiered) | All vendors identified | Spreadsheet |
+| Vendor SOC 2 reports (reviewed) | Critical vendors assessed | SOC 2 report copies + review log |
+| Vendor security questionnaire responses | Due diligence performed | Questionnaire responses |
+| Vendor contracts with security clauses / DPA | Contractual controls in place | Contract excerpts |
+| CUEC (Complementary User Entity Controls) tracking | CUECs from vendor SOC 2 reports addressed | Mapping document |
+
+---
+
+### A1 — Availability
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Uptime monitoring dashboards / SLA reports | System availability tracked | Monitoring tool export (e.g., Datadog, Pingdom) |
+| Capacity monitoring alerts | A1.1 — capacity managed | Dashboard screenshots |
+| Backup completion logs (all backups in period) | Backups running as configured | Backup tool reports |
+| Backup restore test records | A1.2 — backups verified | Test procedure + results document |
+| DR test plan and results | A1.3 — recovery tested | DR test report with date and RTO/RPO achieved |
+| Incident tickets for outages | Availability events documented | Ticket records |
+
+---
+
+### C1 — Confidentiality
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Data inventory / data map | Confidential data identified | Data inventory spreadsheet |
+| Data classification labels applied | C1.1 — classification in practice | Screenshots, DLP reports |
+| DLP (Data Loss Prevention) reports | Confidential data protected | DLP console export |
+| Data disposal/destruction records | C1.2 — disposal per policy | Certificate of destruction, deletion logs |
+| NDA log (employees, vendors) | Confidentiality agreements in place | NDA execution records |
+
+---
+
+### PI1 — Processing Integrity
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Input validation test records | PI1.2 — inputs authorized and validated | Test results, code review records |
+| Reconciliation reports | PI1.3 — outputs complete and accurate | Reconciliation logs |
+| Error log reviews | PI1.4 — errors detected | Error monitoring reports |
+| Data integrity monitoring alerts | PI1.5 — stored items protected | Monitoring screenshots |
+| Job/batch processing success logs | PI1.1 — processing complete | Scheduler/job logs |
+
+---
+
+### P1–P8 — Privacy
+
+| Evidence Item | What it proves | Format |
+|---|---|---|
+| Privacy notice (published, dated) | P1 — notice provided | URL / PDF |
+| Consent mechanism screenshots | P2 — consent obtained | UI screenshots, consent logs |
+| Data subject request (DSR) log | P8 — requests handled | DSR ticket log |
+| DSR response records (sample) | P8 — timely response | Ticket records with dates |
+| Data retention schedule | P5 — retention defined | Retention policy + schedule |
+| Data deletion records | P5 — data disposed per policy | Deletion logs |
+| Privacy impact assessments (PIA) | P3, P4 — collection/use reviewed | PIA documents |
+| Third-party data sharing agreements | P6 — sharing authorized | DPA / data sharing contracts |
+
+---
+
+## Evidence Quality Checklist
+
+Before submitting evidence to auditors, verify:
+
+- [ ] **Dated** — every screenshot or export clearly shows the date it was captured
+- [ ] **System-identified** — it's clear which system the evidence comes from
+- [ ] **Complete for period** — Type 2 evidence covers the full audit window
+- [ ] **Not reconstructed** — evidence was captured at the time of control operation, not created retroactively
+- [ ] **Reviewer-attributable** — approvals show who approved (not just "admin" or a shared account)
+- [ ] **Named with context** — files are named clearly (e.g., `CC6.5_AccessReview_Q3-2024_Signed.pdf`, not `screenshot1.png`)
+- [ ] **Organized by criterion** — evidence folder mirrors the TSC structure
+
+---
+
+## Common Evidence Pitfalls
+
+1. **Screenshots with no date** — always capture the date/timestamp in the screenshot or use system-generated exports with metadata.
+
+2. **"As of today" exports provided after the audit period** — access lists pulled after the fact don't prove controls operated *during* the period. Configure periodic automated exports.
+
+3. **Approval from the same person who made the change** — self-approval violates separation of duties. Flag this for remediation before the audit.
+
+4. **Shared or service accounts used for approvals** — individual accountability cannot be established. Require personal accounts for all approvals.
+
+5. **Training completion reports showing < 100%** — auditors will ask about non-completers. Have a policy and evidence showing follow-up for late completers.
+
+6. **Incomplete incident tickets** — tickets must show: detection time, severity classification, responders, containment actions, resolution, and closure. Sparse tickets are a finding.
+
+7. **Vendor SOC 2 reports not reviewed** — simply *having* a vendor's SOC 2 report is insufficient. Show evidence it was reviewed (e.g., review memo, CUEC tracking).

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

@@ -0,0 +1,254 @@
+# SOC 2 Policy Writing Reference
+
+## Table of Contents
+1. [Policy Writing Standards](#policy-writing-standards)
+2. [Required Policy Set](#required-policy-set)
+3. [Policy Templates](#policy-templates)
+4. [Common Mistakes to Avoid](#common-mistakes-to-avoid)
+
+---
+
+## Policy Writing Standards
+
+### Universal Policy Header
+
+Every policy should start with:
+
+```
+Policy Title:     [Name]
+Policy ID:        [e.g., ISP-001]
+Version:          [e.g., 1.2]
+Effective Date:   [Date]
+Last Reviewed:    [Date]
+Next Review Date: [Date — maximum 12 months from last review]
+Policy Owner:     [Role]
+Approved By:      [Executive/leadership role + name]
+TSC Criteria:     [e.g., CC1.1, CC2.1, CC5.3]
+```
+
+### Required Sections (every policy)
+
+1. **Purpose** — Why this policy exists; what it protects
+2. **Scope** — Who and what systems it applies to (be explicit)
+3. **Policy Statements** — The actual rules (use "must", not "should")
+4. **Roles and Responsibilities** — Who enforces it, who complies
+5. **Exceptions** — How to request an exception; who approves
+6. **Enforcement** — Consequences of non-compliance
+7. **Related Documents** — Links to procedures, standards, other policies
+8. **Review and Revision History** — Version log
+
+### Language Standards
+
+| Weak (avoid) | Strong (use) |
+|---|---|
+| should, may, could | must, shall, is required to |
+| as appropriate | [specific action] |
+| where possible | [specific action or explicit exception process] |
+| periodically | [specific frequency: quarterly, annually] |
+| sensitive data | [defined data classification tier] |
+| promptly | within [X] hours/days |
+
+---
+
+## Required Policy Set
+
+### 1. Information Security Policy (ISP)
+**Criteria:** CC1.1, CC1.2, CC2.1, CC5.1, CC5.3  
+**Purpose:** Overarching policy establishing management's commitment to security  
+**Must include:**
+- Executive statement of commitment
+- Security objectives aligned to business
+- Reference to all subordinate security policies
+- Defined security roles (CISO, security committee, data owners, users)
+- Annual review requirement
+
+---
+
+### 2. Access Control Policy
+**Criteria:** CC6.1, CC6.2, CC6.3, CC6.4, CC6.5, CC6.6  
+**Must include:**
+- Principles: least privilege, need-to-know, separation of duties
+- MFA requirements (which systems require it — be specific)
+- Provisioning process: how access is requested, approved, granted
+- Termination process: timeline for de-provisioning (e.g., within 24 hours)
+- Privileged access: how admin/root access is controlled and reviewed
+- Access review cadence (e.g., quarterly for privileged, annual for standard)
+- Password/authentication standards (or reference to auth policy)
+
+---
+
+### 3. Incident Response Policy
+**Criteria:** CC7.3, CC7.4, CC2.3  
+**Must include:**
+- Incident classification levels (with examples: P1–P4 or Critical/High/Medium/Low)
+- Roles: Incident Commander, responders, communications lead
+- Detection and reporting process (how incidents are identified and escalated)
+- Response phases: Identify → Contain → Eradicate → Recover → Lessons Learned
+- Customer notification SLA (e.g., material breaches within 72 hours)
+- Post-incident review requirement
+- Annual IR tabletop exercise requirement
+
+**Template snippet:**
+```
+4. Incident Classification
+
+Severity 1 (Critical): Confirmed breach of customer data, ransomware, complete
+  system outage. Requires immediate escalation to CEO and CISO. Customer
+  notification within 72 hours if PII involved.
+
+Severity 2 (High): Suspected breach, significant service degradation >30 min,
+  compromised admin credentials. Requires CISO notification within 2 hours.
+
+Severity 3 (Medium): Isolated malware, failed intrusion attempt, minor outage.
+  Requires Security team response within 4 hours.
+
+Severity 4 (Low): Security policy violations, phishing attempts (no compromise),
+  suspicious activity (unconfirmed). Requires ticket within 24 hours.
+```
+
+---
+
+### 4. Change Management Policy
+**Criteria:** CC8.1  
+**Must include:**
+- Scope: what constitutes a "change" (code, infrastructure, configurations)
+- Change types: standard (pre-approved), normal (requires review), emergency
+- Approval requirements by change type
+- Testing requirements (staging/QA before production)
+- Rollback requirements: every change must have a documented rollback plan
+- Emergency change: allowed with retroactive approval within 24 hours
+- Change freeze periods (optional but common)
+
+---
+
+### 5. Risk Assessment Policy
+**Criteria:** CC3.1, CC3.2, CC3.3, CC3.4  
+**Must include:**
+- Frequency: at minimum annual, plus triggered by significant changes
+- Risk scoring methodology (likelihood × impact matrix)
+- Risk tolerance/appetite statement
+- Risk register: ownership, format, review cadence
+- Treatment options: accept, mitigate, transfer, avoid
+- Escalation: who reviews and approves risk acceptance
+
+---
+
+### 6. Vendor Management Policy
+**Criteria:** CC9.2  
+**Must include:**
+- Vendor tiering criteria (Critical / High / Medium / Low)
+- Due diligence requirements per tier (SOC 2 report, questionnaire, etc.)
+- Contractual requirements: DPA, security addendum, right-to-audit
+- Ongoing monitoring: annual review schedule
+- Offboarding: data deletion requirements, access revocation
+- Subprocessor disclosure for customer-facing vendors
+
+---
+
+### 7. Business Continuity & Disaster Recovery Policy
+**Criteria:** A1.2, A1.3, CC9.1  
+**Must include:**
+- RTO (Recovery Time Objective) and RPO (Recovery Point Objective) per system
+- Backup frequency, retention, and verification requirements
+- DR environment description (hot/warm/cold standby)
+- DR test requirement: at minimum annual tabletop or failover test
+- BCP activation criteria and escalation path
+- Communication plan during an incident
+
+---
+
+### 8. Data Classification Policy
+**Criteria:** C1.1, P3, CC6.7  
+**Must include:**
+- Classification tiers (example: Public / Internal / Confidential / Restricted)
+- Definition of each tier with examples
+- Handling requirements per tier (storage, transmission, sharing, disposal)
+- Labeling requirements
+- Default classification (unclassified data = treated as what tier?)
+
+**Template tiers:**
+```
+Restricted:   PII, PHI, payment card data, credentials, encryption keys.
+              Encrypted at rest and in transit. Access strictly limited.
+              Cannot be stored in personal devices or unapproved cloud services.
+
+Confidential: Business-sensitive data, source code, audit reports, contracts.
+              Encrypted in transit. Access on need-to-know basis. NDA required
+              for external sharing.
+
+Internal:     Internal communications, non-sensitive operational data.
+              Not for public distribution. Standard access controls apply.
+
+Public:       Marketing materials, published docs, press releases.
+              No special controls required.
+```
+
+---
+
+### 9. Acceptable Use Policy
+**Criteria:** CC1.1, CC6.6, CC6.8  
+**Must include:**
+- Acceptable use of company systems, networks, and data
+- Prohibited activities (explicit list)
+- Personal device / BYOD rules
+- Monitoring disclosure ("Company may monitor use of systems")
+- Reporting obligations for suspected incidents
+- Acknowledgment requirement (signed annually)
+
+---
+
+### 10. Privacy Policy / Notice
+**Criteria:** P1, P2, P3, P6, P8  
+**Must include (per AICPA GAPP):**
+- What personal information is collected and why
+- Legal basis for processing (if GDPR-applicable)
+- How information is used
+- With whom it is shared (third parties, subprocessors)
+- Retention periods
+- Individual rights (access, correction, deletion, portability)
+- How to submit a data subject request
+- Contact information for privacy inquiries
+- How policy changes are communicated
+
+---
+
+### 11. Encryption Policy
+**Criteria:** CC6.7, C1.1  
+**Must include:**
+- Encryption standards (e.g., AES-256 at rest, TLS 1.2+ in transit)
+- Which systems and data require encryption
+- Key management: generation, rotation, storage, destruction
+- Prohibition on deprecated algorithms (MD5, SHA-1, DES, RC4)
+
+---
+
+### 12. Vulnerability Management Policy
+**Criteria:** CC7.1, CC7.5  
+**Must include:**
+- Scanning frequency (e.g., weekly automated + quarterly penetration test)
+- Severity-based remediation SLAs:
+  - Critical: patch within 24–72 hours
+  - High: patch within 7–14 days
+  - Medium: patch within 30 days
+  - Low: patch within 90 days or accepted risk
+- Exception process for systems that can't be patched immediately
+- Penetration testing requirement (annual minimum)
+- Responsible disclosure / bug bounty program (optional)
+
+---
+
+## Common Mistakes to Avoid
+
+1. **Writing policies that describe the ideal, not the actual** — auditors test what you do, not what you aspirationally wrote. Only commit to what you'll consistently do.
+
+2. **No approval signatures** — policies must be formally approved by an appropriate executive or the board.
+
+3. **Copy-paste from the internet** — boilerplate policies often contain controls you don't have. Every control stated must be evidenced.
+
+4. **Missing scope statements** — "this policy applies to all employees" may be incomplete if contractors, vendors, or specific systems need to be called out.
+
+5. **Not distributing policies** — policies must be accessible to all in-scope personnel. Distribution evidence is required (e.g., intranet link, email announcement, acknowledgment log).
+
+6. **Neglecting annual review** — dated policies are a flag. Every policy must have a documented review with any changes noted.
+
+7. **Procedures missing from policies** — policies state *what* and *why*; procedures state *how*. Both are needed. "We will respond to incidents" without a runbook is a gap.