bmad-plus 0.4.4 → 0.5.0

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

@@ -0,0 +1,366 @@
+# PCI DSS v4.0.1 — All 12 Requirements
+
+Source: PCI DSS v4.0.1 (PCI Security Standards Council, June 2024)
+https://www.pcisecuritystandards.org/document_library/
+
+---
+
+## GOAL 1: Build and Maintain a Secure Network and Systems
+
+### Requirement 1 — Install and Maintain Network Security Controls
+
+Network security controls (NSCs) — firewalls, routers, cloud security groups — prevent unauthorised network access to and from the CDE.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 1.1 | NSC policies and procedures are defined, implemented, and maintained | Policy docs, network diagrams, change records |
+| 1.2 | NSC configurations restrict traffic to only what is necessary | Firewall/router ruleset review, deny-all default |
+| 1.2.1 | Configuration standards for NSCs are defined | Documented baseline standards |
+| 1.2.2 | NSC configuration changes are managed via change control | Change tickets, approval records |
+| 1.2.3 | Network diagrams are current and accurate | Dated network diagram showing CDE boundaries |
+| 1.2.4 | Data-flow diagrams for all account data flows are current | Data flow diagrams (DFDs) |
+| 1.2.5 | All allowed services/ports are documented with business justification | Firewall rule documentation |
+| 1.2.6 | Security features for each service are documented and implemented | Config baselines per service |
+| 1.2.7 | NSC configurations are reviewed at least every 6 months | Review records with dates and approvers |
+| 1.3 | Inbound and outbound network traffic is restricted to only that necessary | Egress filtering, deny-all-else rules |
+| 1.3.1 | Inbound traffic to CDE restricted to authorised sources and services | Firewall rules reviewed |
+| 1.3.2 | Outbound traffic from CDE restricted to authorised destinations | Egress rules documented |
+| 1.3.3 | NSCs installed between wireless networks and CDE | Wireless-to-CDE firewall rules |
+| 1.4 | Network connections between trusted and untrusted networks controlled | DMZ architecture, traffic inspection |
+| 1.4.1 | NSCs between trusted/untrusted networks inspect and filter traffic | Stateful inspection, IDS/IPS |
+| 1.4.2 | Inbound traffic from untrusted networks: no direct routes to CDE | No direct routing; proxy/DMZ required |
+| 1.4.3 | Anti-spoofing measures to detect and block forged source IP addresses | Anti-spoofing ACLs, RFC 3704 filtering |
+| 1.4.4 | Unauthorised traffic (cardholder data) blocked from entering untrusted networks | DLP rules or network controls |
+| 1.4.5 | Internal IP addresses not disclosed to unauthorised parties | NAT, private RFC 1918 space |
+| 1.5 | Risks from device connectivity to untrusted networks are managed | Endpoint security controls |
+| 1.5.1 | Security controls for devices connecting to both untrusted and trusted networks | MDM/endpoint policy, split tunnelling controls |
+
+**Common gaps**: Stale firewall rules never reviewed; no egress filtering; flat network (no CDE isolation); wireless networks not separated from CDE.
+
+---
+
+### Requirement 2 — Apply Secure Configurations to All System Components
+
+Default credentials and unnecessary services must be eliminated before deployment.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 2.1 | Processes for managing vendor defaults and other security parameters | Hardening policy, config standards |
+| 2.2 | System configuration standards are developed and implemented | CIS Benchmark or equivalent; per platform standard |
+| 2.2.1 | System configuration standards address all known security vulnerabilities | Vuln scan results mapped to standards |
+| 2.2.2 | Vendor default accounts managed before deploying systems | Default creds disabled/renamed; evidence of removal |
+| 2.2.3 | Primary functions needing different security levels are on separate components | Server isolation, role separation |
+| 2.2.4 | Only necessary functions, ports, protocols, and services are enabled | Port scan results; services audit |
+| 2.2.5 | If insecure protocols are used, business justification and additional controls documented | Protocol exception log |
+| 2.2.6 | System security parameters are configured to prevent misuse | Config hardening evidence |
+| 2.2.7 | All non-console administrative access is encrypted | SSH, HTTPS, TLS for all admin access |
+| 2.3 | Wireless environments are configured and managed securely | Wi-Fi config review, WPA3 or WPA2-Enterprise |
+| 2.3.1 | Default wireless vendor defaults changed at installation | AP config records |
+| 2.3.2 | Wireless encryption keys changed when anyone with key knowledge leaves | Key rotation procedure and evidence |
+
+**Common gaps**: Vendor default passwords left unchanged; unnecessary services (Telnet, FTP) still enabled; no documented hardening standards.
+
+---
+
+## GOAL 2: Protect Account Data
+
+### Requirement 3 — Protect Stored Account Data
+
+Minimise storage of account data; never store SAD post-authorisation; protect PAN wherever stored.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 3.1 | Processes for protecting stored account data are defined and implemented | Data retention policy |
+| 3.2 | Account data storage minimised | Data retention schedules; deletion procedures |
+| 3.2.1 | SAD not retained after authorisation | Scan results proving no SAD in storage; code review |
+| 3.3 | SAD is not retained after authorisation | Confirmed by system scans and application review |
+| 3.3.1 | SAD not stored (full magnetic stripe, CAV2/CVV2/CVC2/CID, PIN/PIN block) | Application code review; database scans |
+| 3.3.2 | SAD stored prior to authorisation is encrypted | Encryption evidence for pre-auth data |
+| 3.3.3 | Encryption keys for pre-auth SAD are managed securely | Key management docs |
+| 3.4 | PAN is protected wherever it is stored | Encryption, masking, or tokenisation evidence |
+| 3.4.1 | PAN is unreadable anywhere it is stored | AES-256 encryption; tokenisation proof; masking |
+| 3.4.2 | Copies of PAN only on authorised removable media | Media inventory and controls |
+| 3.5 | PAN is secured with strong cryptography | Encryption algorithm and key management review |
+| 3.5.1 | Primary account numbers protected with strong cryptography | AES-256 or equivalent; no DES/RC4 |
+| 3.6 | Cryptographic keys used for PAN encryption are secured | Key management policy and procedures |
+| 3.6.1 | Key management procedures and processes for cryptographic keys | Key custodian assignments; split knowledge |
+| 3.7 | Key management procedures and processes are implemented | Key rotation, key-encrypting keys, key retirement |
+| 3.7.1 | Key management policies cover the full key lifecycle | Generated, distributed, stored, retired |
+| 3.7.2 | Key storage is secure | HSM, encrypted key store |
+| 3.7.3 | Key access restricted to fewest custodians necessary | Dual control; split knowledge |
+| 3.7.4 | Key retirement/replacement policy documented and followed | Rotation records |
+| 3.7.5 | Key compromises managed per documented procedure | Incident response for key compromise |
+| 3.7.6 | Manual keys use split knowledge and dual control | Evidence of two-person key operations |
+| 3.7.7 | Informal key substitution prevented | Formal key management only |
+| 3.7.8 | Key custodians acknowledge their responsibilities | Signed custodian agreements |
+| 3.7.9 | Where key management services are used, they meet Req 3.6–3.7 | CSP KMS compliance evidence |
+
+**Common gaps**: CVV stored in database; PAN in log files; no key rotation; encryption with weak algorithms (MD5, SHA-1 for integrity); keys stored alongside encrypted data.
+
+---
+
+### Requirement 4 — Protect Cardholder Data with Strong Cryptography During Transmission
+
+PAN transmitted over open, public networks must be encrypted using strong cryptography.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 4.1 | Processes for protecting PAN in transit are defined and implemented | Cryptography policy |
+| 4.2 | PAN protected during transmission over open, public networks | TLS 1.2+ config; certificate review |
+| 4.2.1 | Strong cryptography used to safeguard PAN in transit | TLS 1.2 or 1.3; no SSL, TLS 1.0, 1.1 |
+| 4.2.1.1 | Certificate inventory maintained | Certificate management tool or inventory |
+| 4.2.1.2 | Wireless networks transmitting PAN use strong cryptography | Wi-Fi encryption: WPA2-Enterprise or WPA3 |
+| 4.2.2 | PAN not sent by unprotected end-user messaging (email, chat) | DLP policy; email encryption controls |
+
+**Common gaps**: Legacy TLS 1.0/1.1 still enabled; expired SSL certificates; PAN sent via plain email; no certificate inventory.
+
+---
+
+## GOAL 3: Maintain a Vulnerability Management Program
+
+### Requirement 5 — Protect All Systems and Networks from Malicious Software
+
+Anti-malware controls protect against viruses, ransomware, spyware, and other threats.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 5.1 | Processes for malware protection are defined | Anti-malware policy |
+| 5.2 | Anti-malware solution(s) deployed on all applicable components | AV deployment inventory; management console |
+| 5.2.1 | Anti-malware solution deployed on all components subject to malware | Coverage report; exceptions documented |
+| 5.2.2 | Anti-malware solution detects all known types of malware | Vendor capability matrix |
+| 5.2.3 | Systems not commonly affected by malware are evaluated periodically | Periodic risk analysis; documented exceptions |
+| 5.3 | Anti-malware solution maintained and monitored | Definition update logs; scan results |
+| 5.3.1 | Anti-malware solution kept current | Auto-update policy; current definition proof |
+| 5.3.2 | Anti-malware performs periodic scans and active/real-time scanning | Scan schedule; real-time protection enabled |
+| 5.3.3 | Anti-malware solution for removable media | USB scanning policy; endpoint config |
+| 5.3.4 | Anti-malware solution logs maintained and monitored | Log retention; SIEM integration |
+| 5.3.5 | Anti-malware mechanisms cannot be disabled by users | Admin-only uninstall; tamper protection enabled |
+| 5.4 | Anti-phishing mechanisms protect users (**NEW in v4.0**) | Anti-phishing filter; email gateway config |
+| 5.4.1 | Automated technical solution detects and protects against phishing | Email security gateway; URL filtering; DMARC/DKIM/SPF |
+
+**Common gaps**: AV not covering Linux/Unix systems; definitions not auto-updated; users can disable AV; no phishing protections (new v4.0 requirement).
+
+---
+
+### Requirement 6 — Develop and Maintain Secure Systems and Software
+
+Vulnerabilities must be identified and addressed through patching and secure development practices.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 6.1 | Security vulnerability identification and management processes defined | Vuln management policy |
+| 6.2 | Bespoke and custom software is developed securely | SDLC policy; code review process |
+| 6.2.1 | Bespoke software developed based on secure coding guidelines | Coding standards; training records |
+| 6.2.2 | Software development personnel trained on secure coding techniques | Annual training records |
+| 6.2.3 | Code review performed before production release | Code review records; SAST scan results |
+| 6.2.4 | Software engineering techniques to prevent common vulnerabilities | OWASP Top 10 addressed; DAST results |
+| 6.3 | Security vulnerabilities identified and addressed | Patch management policy |
+| 6.3.1 | Security vulnerabilities managed using ranking | CVSS or internal risk ranking; patch SLAs |
+| 6.3.2 | Inventory of bespoke and custom software maintained | Software inventory/SBOM |
+| 6.3.3 | All system components protected from known vulnerabilities | Patch management; current patch evidence |
+| 6.4 | Public-facing web applications protected from attacks | WAF or application review |
+| 6.4.1 | Public-facing web apps protected against web-based attacks | WAF in blocking mode; annual app testing |
+| 6.4.2 | Automated technical solution deployed for public-facing web apps | WAF config; active monitoring |
+| 6.4.3 | All payment page scripts managed and authorised (**NEW v4.0**) | Script inventory; integrity controls |
+| 6.5 | Changes to system components managed securely | Change management policy |
+| 6.5.1 | Changes to system components via formal change control | Change tickets; approval evidence |
+| 6.5.2 | Post-change security verification | Test results; UAT sign-off |
+| 6.5.3 | Pre-production environments are separate from production | Environment separation proof |
+| 6.5.4 | Roles and functions are separated between production and pre-production | Access control evidence |
+| 6.5.5 | Live PANs not used in pre-production/testing | Anonymised test data confirmation |
+| 6.5.6 | Test data/accounts removed before production | Pre-prod cleanup checklist |
+
+**Common gaps**: No SDLC/secure coding policy; live PANs in test environments; WAF in detection-only mode; payment page scripts not inventoried (v4.0 new).
+
+---
+
+## GOAL 4: Implement Strong Access Control Measures
+
+### Requirement 7 — Restrict Access to System Components and Cardholder Data by Business Need to Know
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 7.1 | Access control processes and procedures defined | Access control policy |
+| 7.2 | Access to system components and cardholder data is restricted | Role-based access matrix; IAM configuration |
+| 7.2.1 | All users have access based on least privilege and need-to-know | Access review results |
+| 7.2.2 | Access assigned based on job classification and function | Role definitions; access request records |
+| 7.2.3 | Privilege access approved by authorised personnel | Approval workflow records |
+| 7.2.4 | User accounts and access privileges reviewed at least every 6 months | Access review logs with dates |
+| 7.2.5 | Application/system accounts managed by policy | Service account inventory; access controls |
+| 7.2.6 | Query access to CHD repositories restricted to defined applications | DB access controls; application-level auth |
+| 7.3 | Access to system components and data is managed | IAM system; access control enforcement |
+| 7.3.1 | Access control system in place to restrict access to CDE | IAM/PAM tool deployment evidence |
+| 7.3.2 | Access control system configured to enforce least privilege | ACL review; deny-by-default configuration |
+| 7.3.3 | Access control system is kept current | Review and update cycle evidence |
+
+**Common gaps**: Shared accounts; no access recertification; over-privileged service accounts; no need-to-know principle enforced for database access.
+
+---
+
+### Requirement 8 — Identify Users and Authenticate Access to System Components
+
+Every user must have a unique ID; strong authentication required for CDE access.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 8.1 | User identification and authentication processes defined | Authentication policy |
+| 8.2 | User IDs and authentication credentials managed | IAM system; unique account verification |
+| 8.2.1 | All users have a unique ID | Account audit; no shared accounts |
+| 8.2.2 | Group, shared, or generic accounts managed only in exceptional circumstances | Exceptions with justification documented |
+| 8.2.3 | Additional authentication for accounts used by third parties/vendors | MFA for vendor access |
+| 8.2.4 | User accounts added/modified/deleted only through formal process | Identity lifecycle management records |
+| 8.2.5 | Access for terminated users is immediately revoked | Offboarding checklist; IAM de-provisioning evidence |
+| 8.2.6 | Inactive accounts disabled within 90 days | Account review; automated disable policy |
+| 8.2.7 | Accounts used for system/application functions managed appropriately | Service account policy compliance |
+| 8.2.8 | Sessions inactive more than 15 minutes require re-authentication | Session timeout config |
+| 8.3 | Strong authentication established and managed | MFA configuration evidence |
+| 8.3.1 | All user access into CDE uses MFA (**Extended in v4.0**) | MFA deployment proof for ALL CDE access |
+| 8.3.2 | MFA for all access into the CDE from outside | Remote access MFA (VPN, RDP, etc.) |
+| 8.3.4 | Invalid authentication attempts limited | Account lockout policy (max 10 attempts) |
+| 8.3.5 | Passwords/passphrases set to meet minimum requirements | Password policy config: min 12 chars, complexity |
+| 8.3.6 | Passwords changed every 90 days (or with compensating control/risk analysis) | Password policy; expiry settings |
+| 8.3.7 | Individuals not allowed to submit new password same as any of last 4 | Password history settings |
+| 8.3.8 | Authentication policies communicated to users | Training records; policy acknowledgements |
+| 8.3.9 | Passwords for users not using MFA changed at least every 90 days | Password expiry config |
+| 8.3.10 | Guidance for changing passwords provided to users at specified intervals | Comms records |
+| 8.4 | MFA implemented for all access into the CDE | MFA for all privileged and standard user access |
+| 8.4.1 | MFA for all non-console admin access to CDE | Admin MFA config |
+| 8.4.2 | MFA for all access into the CDE (**Key new v4.0 change**) | MFA required for everyone accessing CDE |
+| 8.5 | MFA systems configured to prevent misuse | Anti-MFA-bypass controls |
+| 8.6 | Use of application/system accounts managed | Automated or manual interactive use controls |
+
+**Common gaps**: Shared admin accounts; weak passwords (< 12 chars); no MFA for all CDE access (key v4.0 gap); accounts not disabled within 90 days of inactivity; no session timeout.
+
+---
+
+### Requirement 9 — Restrict Physical Access to Cardholder Data
+
+Physical controls prevent unauthorised access to systems, media, and facilities in the CDE.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 9.1 | Processes for restricting physical access defined | Physical security policy |
+| 9.2 | Physical access controls for appropriate facility entry | Badge access logs; visitor records |
+| 9.2.1 | Individual physical access controls to sensitive areas | Badge reader logs; CCTV |
+| 9.2.2 | Visitor management procedure implemented | Visitor log; escort policy |
+| 9.2.3 | Physical access to wireless access points, gateways, and handheld devices controlled | Device location inventory; lock-down evidence |
+| 9.2.4 | Physical access to CDE systems via publicly accessible network jacks controlled | Port lock-out; network access control |
+| 9.3 | Physical access for personnel and visitors authorised and managed | Access management records |
+| 9.3.1 | Physical access controls for personnel with physical access | Access list; revocation process |
+| 9.3.2 | Physical access for visitors authorised and revoked | Visitor badge records |
+| 9.4 | Media with cardholder data is securely stored, accessed, distributed, and destroyed | Media inventory; destruction records |
+| 9.4.1 | Physical media containing CHD secured | Locked storage; media inventory |
+| 9.4.2 | Physical media containing CHD classified | Classification labels on media |
+| 9.4.3 | Physical media distributed externally via tracked courier or secure methods | Courier receipts; chain of custody |
+| 9.4.4 | Management approval for all media moved outside facility | Approval records |
+| 9.4.5 | External media inventory controlled and audited | Media audit logs |
+| 9.4.6 | Hard-copy materials with CHD destroyed cross-cut or confetti-shred | Destruction vendor certificates |
+| 9.4.7 | Electronic media destroyed or rendered unrecoverable when no longer needed | Secure wipe / degauss / physical destroy records |
+| 9.5 | Point-of-interaction (POI) devices protected from tampering and skimming | POI device inspection programme |
+| 9.5.1 | POI device surface inspected to detect tampering or substitution | Inspection schedule; checklist records |
+
+**Common gaps**: No visitor log; POI devices not regularly inspected; media not tracked or destroyed per policy; physical access not revoked for terminated staff.
+
+---
+
+## GOAL 5: Regularly Monitor and Test Networks
+
+### Requirement 10 — Log and Monitor All Access to System Components and Cardholder Data
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 10.1 | Audit log processes defined | Log management policy |
+| 10.2 | Audit logs implemented to support detection of anomalies | SIEM or log management platform |
+| 10.2.1 | Audit logs capture all individual user access to CHD | Log samples showing user activity |
+| 10.2.2 | Audit logs capture all actions by root or admin | Privileged access logs |
+| 10.2.3 | Audit logs capture all access to audit logs | Audit-of-audit trail |
+| 10.2.4 | Audit logs capture invalid logical access attempts | Failed login logs |
+| 10.2.5 | Audit logs capture use of identification and authentication mechanisms | Auth logs; MFA event logs |
+| 10.2.6 | Audit logs capture initialisation, stopping, or pausing of logs | Log service event logs |
+| 10.2.7 | Audit logs capture creation/deletion of system-level objects | System event logs |
+| 10.3 | Audit logs are protected from destruction and modification | Log integrity controls; write-once storage |
+| 10.3.1 | Log files protected to prevent modifications | Immutable log storage; SIEM ingestion |
+| 10.3.2 | Audit log files protected from unauthorised access | Access controls on log infrastructure |
+| 10.3.3 | Audit logs are promptly backed up to a central log server | Syslog/SIEM centralisation evidence |
+| 10.3.4 | File integrity monitoring or change detection on audit logs | FIM solution monitoring log files |
+| 10.4 | Audit logs reviewed to identify anomalies or suspicious activity | Log review process |
+| 10.4.1 | Automated log review mechanisms used (**NEW in v4.0**) | SIEM alert rules; automated review evidence |
+| 10.4.2 | Logs for all system components reviewed daily | Review schedules; SIEM alert evidence |
+| 10.4.3 | Exceptions and anomalies addressed promptly | Ticket records tied to log alerts |
+| 10.5 | Audit log history retained for at least 12 months with last 3 months immediately available | Retention policy; log storage capacity |
+| 10.6 | Time synchronisation technology in use | NTP configuration; stratum 1/2 sync |
+| 10.7 | Failures of critical security controls detected and addressed (**NEW in v4.0**) | Monitoring for AV, FW, IDS failures |
+| 10.7.2 | Failures detected and responded to promptly | Alert/ticketing evidence |
+
+**Common gaps**: Logs not centralised to SIEM; retention under 12 months; no automated review (v4.0 new); time not synchronised across all CDE components; critical security control failures not monitored.
+
+---
+
+### Requirement 11 — Test Security of Systems and Networks Regularly
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 11.1 | Security testing processes defined | Testing policy |
+| 11.2 | Wireless access points managed | Wireless AP inventory; rogue AP detection |
+| 11.2.1 | Authorised and unauthorised wireless access points managed | Quarterly wireless scans; rogue detection alerts |
+| 11.2.2 | Wireless scan inventory reconciled quarterly | Scan results vs inventory |
+| 11.3 | External and internal vulnerabilities assessed | Vulnerability scanning programme |
+| 11.3.1 | Internal vulnerability scans run at least every 3 months | Scan reports showing quarterly cadence |
+| 11.3.2 | External vulnerability scans run at least every 3 months by an ASV | ASV scan reports; passing results |
+| 11.3.3 | All exploitable vulnerabilities remediated and re-scanned | Remediation evidence; re-scan passing results |
+| 11.4 | External and internal penetration testing is performed | Penetration test reports |
+| 11.4.1 | Penetration testing methodology defined | Pen test scope document |
+| 11.4.2 | Internal penetration testing at least annually and after changes | Annual pen test report |
+| 11.4.3 | External penetration testing at least annually and after changes | External pen test report |
+| 11.4.4 | Exploitable vulnerabilities from pen testing remediated and re-tested | Remediation tracking; re-test confirmation |
+| 11.4.5 | Network segmentation verified by penetration testing at least every 6 months | Segmentation pen test report |
+| 11.5 | Network intrusion detection/prevention techniques used | IDS/IPS deployment evidence |
+| 11.5.1 | Intrusion detection/prevention used to detect and/or prevent intrusions | IDS/IPS alert logs; tuning records |
+| 11.5.2 | Change detection mechanism deployed on CDE | FIM solution alerts; change records |
+| 11.6 | Unauthorised changes on payment pages detected and responded to (**NEW v4.0**) | Script integrity monitoring |
+| 11.6.1 | Change and tamper detection mechanism for payment pages deployed | HTTP header monitoring; script hash verification |
+
+**Common gaps**: ASV scans failing (not "clean"); penetration testing not truly internal + external; segmentation not tested; no FIM; payment page integrity not monitored (v4.0 new).
+
+---
+
+## GOAL 6: Maintain an Information Security Policy
+
+### Requirement 12 — Support Information Security with Organizational Policies and Programs
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 12.1 | Comprehensive information security policy defined, published, and maintained | Security policy doc; annual review |
+| 12.2 | Targeted risk analysis process defined for flexible requirements | TRA template; completed TRAs |
+| 12.3 | Risks to CHD and cardholder data environment managed | Risk management programme |
+| 12.3.1 | Targeted risk analysis for each PCI DSS requirement with customised approach | TRA documentation per requirement |
+| 12.3.2 | TRA performed for flexible-frequency requirements | Documented TRAs for each flexible req |
+| 12.3.3 | Cryptographic cipher suites and protocols reviewed and documented at least once every 12 months | Crypto inventory; annual review records |
+| 12.3.4 | Hardware and software technologies reviewed at least once every 12 months | Tech lifecycle review records |
+| 12.4 | PCI DSS compliance managed throughout the year | Compliance programme; quarterly review |
+| 12.4.2 | Reviews confirming personnel follow security policies performed at least quarterly | Quarterly compliance review records |
+| 12.5 | PCI DSS scope documented and validated | Scope documentation; annual review |
+| 12.5.1 | Inventory of system components in scope for PCI DSS maintained | CDE system inventory |
+| 12.5.2 | PCI DSS scope verified at least every 12 months and after major changes | Annual scope review; post-change assessment |
+| 12.6 | Security awareness education implemented | Security awareness programme; training records |
+| 12.6.1 | Security awareness programme in place | Programme documentation |
+| 12.6.2 | Security awareness programme reviewed at least every 12 months | Review records |
+| 12.6.3 | Personnel acknowledge at least annually they have read and understood security policy | Signed acknowledgements |
+| 12.7 | Personnel are screened before granting access to CDE | Background check policy; records |
+| 12.8 | Third-party service providers (TPSPs) with CHD access are managed | TPSP inventory; compliance monitoring |
+| 12.8.1 | List of all TPSPs maintained | TPSP register |
+| 12.8.2 | Written agreements with TPSPs acknowledging PCI DSS responsibility | Signed agreements |
+| 12.8.3 | Established process for engaging TPSPs | TPSP due diligence process |
+| 12.8.4 | TPSP PCI DSS compliance status monitored at least annually | Annual TPSP compliance confirmation; AOC |
+| 12.8.5 | Information about which PCI DSS requirements managed by each TPSP | Responsibility matrix |
+| 12.9 | TPSPs support customers' PCI DSS compliance | TPSP acknowledgement of responsibility |
+| 12.10 | Suspected and confirmed security incidents responded to immediately | Incident response plan; test records |
+| 12.10.1 | Incident response plan created and ready | Documented IR plan |
+| 12.10.2 | IR plan reviewed and tested at least annually | Annual tabletop or drill evidence |
+| 12.10.3 | Specific personnel designated for 24/7 incident response | On-call roster; contact list |
+| 12.10.4 | IR personnel trained appropriately | Annual training records |
+| 12.10.5 | Alerts from security monitoring systems included in IR plan | IR plan references monitoring alerts |
+| 12.10.6 | IR plan updated when new threats or lessons learned | Version history; update records |
+| 12.10.7 | Incident response procedures for discovery of stored PAN in unexpected location | PAN discovery procedure |
+
+**Common gaps**: Security policy not reviewed annually; no TPSP register or compliance monitoring; incident response plan never tested; personnel not acknowledging policy; no TRA process.

package/src/bmad-plus/packs/pack-shield/references/pci-compliance/pci-dss-saq-guide.md

@@ -0,0 +1,217 @@
+# PCI DSS v4.0.1 — SAQ Selection Guide
+
+Source: PCI DSS v4.0 SAQ documents (PCI Security Standards Council)
+https://www.pcisecuritystandards.org/document_library/
+
+---
+
+## What is a Self-Assessment Questionnaire (SAQ)?
+
+An SAQ is a validation tool intended to assist merchants and service providers in self-evaluating their compliance with PCI DSS. There are multiple SAQ types — each designed for a specific payment channel and cardholder data environment profile. The correct SAQ type depends on **how** your organisation accepts payments and **who** handles cardholder data.
+
+Level 1 merchants and Level 1 service providers are **not eligible** for SAQs — they require an on-site Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA).
+
+---
+
+## SAQ Selection Decision Tree
+
+**Step 1: Are you a Level 1 Merchant or Level 1 Service Provider?**
+- Yes → ROC required (not an SAQ). Stop here.
+- No → Continue to Step 2.
+
+**Step 2: Are you a Service Provider (not a merchant)?**
+- Yes → **SAQ D for Service Providers** (unless Level 1)
+- No (Merchant) → Continue to Step 3.
+
+**Step 3: Do you accept card-present (face-to-face) transactions?**
+- Yes, using ONLY imprint machines (no electronic transactions) → **SAQ B**
+- Yes, using ONLY standalone dial-out terminals (no IP connectivity) → **SAQ B**
+- Yes, using standalone IP-connected PTS POI devices only → **SAQ B-IP**
+- Yes, using a validated P2PE solution only (PCI-listed) → **SAQ P2PE**
+- Yes, using virtual payment terminals (isolated device, web-based) → **SAQ C-VT**
+- Yes, using payment application systems connected to internet → **SAQ C**
+- Yes, with any other scenario → **SAQ D for Merchants**
+
+**Step 4: Do you accept card-not-present (CNP) — e-commerce or MOTO — only?**
+- Yes, and ALL cardholder data functions fully outsourced, no redirect control → **SAQ A**
+- Yes, e-commerce only, but you control the customer redirect to the payment page → **SAQ A-EP**
+- Yes, MOTO only with virtual payment terminals (web-based, isolated device) → **SAQ C-VT**
+- Any other CNP scenario → **SAQ D for Merchants**
+
+---
+
+## SAQ Types — Full Reference
+
+### SAQ A — Fully Outsourced Card-Not-Present
+**Applies to**: E-commerce and/or MOTO (mail order/telephone order) merchants only. No card-present transactions. All cardholder data functions (storage, processing, transmission) fully outsourced to PCI DSS-compliant third-party service providers. Merchant retains no electronic cardholder data.
+
+**Requirements covered**: Subset of Req 2, 6, 8, 9, 10, 11, 12 (~22 controls)
+
+**Eligibility criteria**:
+- Cards not present at any time during the transaction
+- All payment processing delegated to a PCI-compliant third party
+- Merchant website does not directly receive cardholder data
+- No cardholder data stored, processed, or transmitted by merchant systems or premises
+
+**Examples**: Merchant uses a payment link or hosted payment page (Stripe, PayPal, Square Checkout). Customer is redirected completely to the provider's hosted page.
+
+---
+
+### SAQ A-EP — E-commerce with Partial Outsourcing
+**Applies to**: E-commerce merchants ONLY. Merchant outsources payment processing but controls/influences how the customer is directed to the payment service. No card-present transactions.
+
+**Requirements covered**: Subset of Req 2, 6, 8, 9, 10, 11, 12 (~191 controls)
+
+**Eligibility criteria**:
+- E-commerce only; no card-present
+- Merchant's website includes payment page elements or partially controls redirect
+- All cardholder data capture outsourced to compliant third party
+- Merchant systems do not receive, store, process, or transmit CHD
+
+**Examples**: Merchant website uses JavaScript-based payment widgets or iFrames that embed third-party payment capture within the merchant's own page.
+
+**Key distinction from SAQ A**: SAQ A-EP requires script integrity controls (Req 6.4.3, 11.6.1) because the merchant controls the page hosting the widget.
+
+---
+
+### SAQ B — Imprint Machines or Standalone Dial-Out Terminals
+**Applies to**: Merchants using ONLY imprint machines (knuckle-busters) OR standalone, dial-out (non-IP) terminals. No e-commerce.
+
+**Requirements covered**: Subset of Req 2, 8, 9, 10, 11, 12 (~41 controls)
+
+**Eligibility criteria**:
+- Transactions processed only via imprint machines or dial-out (telephone-line) terminals
+- Terminals not IP-connected and not connected to any other system in the environment
+- No electronic cardholder data stored on any computer system
+- No e-commerce
+
+**Examples**: Small retail using a standalone Dial-Up terminal or old knuckle-buster imprinter.
+
+---
+
+### SAQ B-IP — Standalone IP-Connected PTS POI Devices
+**Applies to**: Merchants using ONLY standalone PTS (PIN Transaction Security) POI devices with IP connectivity. Devices must be PCI-listed PTS POI devices. No e-commerce.
+
+**Requirements covered**: Subset of Req 1, 2, 6, 8, 9, 10, 11, 12 (~83 controls)
+
+**Eligibility criteria**:
+- ONLY standalone PCI-listed PTS POI devices with IP connection used
+- Devices not connected to any other system in the merchant environment
+- No e-commerce
+
+**Examples**: Merchant using a certified IP-connected payment terminal (e.g., Ingenico, Verifone) with an IP connection but isolated from other systems.
+
+---
+
+### SAQ C-VT — Virtual Payment Terminals (Web-Based)
+**Applies to**: Merchants using only web-based virtual payment terminal solutions accessed via a web browser on an isolated computing device. No e-commerce; no cardholder data electronically stored.
+
+**Requirements covered**: Subset of Req 1, 2, 6, 8, 9, 10, 11, 12 (~90 controls)
+
+**Eligibility criteria**:
+- Payment processing via web-browser virtual terminal only
+- Device used for virtual terminal is isolated and dedicated to payment processing
+- No cardholder data storage on any system
+- No card-present (physical card swiped) via this method
+- Device not connected to other systems in the environment
+
+**Examples**: MOTO merchant logs into a hosted virtual terminal (e.g., PayPal Virtual Terminal, Authorize.Net) on a dedicated PC to key-enter card details.
+
+---
+
+### SAQ C — Payment Application Systems Connected to Internet
+**Applies to**: Merchants with payment application systems connected to the internet. No e-commerce. Device/application(s) not connected to other systems in the environment.
+
+**Requirements covered**: Subset of Req 1, 2, 5, 6, 8, 9, 10, 11, 12 (~160 controls)
+
+**Eligibility criteria**:
+- Payment application connected to internet (e.g., point-of-sale system with internet connectivity)
+- Not an e-commerce channel
+- Payment application not connected to other systems within the facility (segmented)
+- No electronic storage of CHD after authorisation
+
+**Examples**: Retail merchant using an internet-connected POS application (e.g., Square POS, Lightspeed) on a device isolated from other business systems.
+
+---
+
+### SAQ P2PE — Validated P2PE Solution
+**Applies to**: Merchants using ONLY hardware payment terminals in a PCI-validated, PCI-listed P2PE solution. No e-commerce.
+
+**Requirements covered**: Very small subset of Req 9, 12 (~33 controls)
+
+**Eligibility criteria**:
+- ALL cardholder data captured via terminals included in a PCI-validated P2PE solution
+- P2PE solution is on the PCI SSC list of validated P2PE solutions
+- No e-commerce
+- Merchant has no access to clear-text CHD
+
+**Examples**: Merchant using a Verifone or Ingenico terminal within a certified P2PE solution (e.g., Bluefin PayConex P2PE, Worldpay Total P2PE).
+
+**Key benefit**: Dramatically reduces PCI DSS scope — merchants only attest to physical security of terminals and selecting a compliant P2PE provider.
+
+---
+
+### SAQ D — All Other Merchants and Service Providers
+
+**SAQ D for Merchants**
+**Applies to**: All merchants who do not meet criteria for SAQ A, A-EP, B, B-IP, C, C-VT, or P2PE. Covers all 12 PCI DSS requirements.
+
+**Requirements covered**: All 12 requirements (~340+ controls)
+
+**Examples**: Merchants that store CHD, have complex multi-channel environments, or don't qualify for a simpler SAQ.
+
+---
+
+**SAQ D for Service Providers**
+**Applies to**: All service providers eligible for SAQ validation (Level 2 service providers). Covers all 12 PCI DSS requirements.
+
+**Requirements covered**: All 12 requirements (~340+ controls, service-provider-specific questions)
+
+**Note**: Service providers have additional requirements vs merchants, particularly around Req 12.8 (TPSP management), Req 12.9 (TPSP acknowledgement), and Req 3.3.2 (SAD protection).
+
+---
+
+## Report on Compliance (ROC)
+
+An ROC is required for:
+- **Level 1 Merchants**: >6 million Visa/MC transactions per year, OR any merchant that has suffered a breach that resulted in account data compromise
+- **Level 1 Service Providers**: >300,000 transactions per year OR designated by a card brand
+
+**ROC process**:
+1. Engage a Qualified Security Assessor (QSA) from the PCI SSC's list
+2. QSA performs on-site assessment against all applicable PCI DSS controls
+3. QSA completes the ROC Template (v4.0.1 template released 2024)
+4. Organisation completes the Attestation of Compliance (AOC) signed by QSA and officer
+5. Submit ROC + AOC to acquiring bank or card brand
+
+---
+
+## Attestation of Compliance (AOC)
+
+The AOC is a declaration of the organisation's PCI DSS compliance status. It is:
+- Completed alongside the ROC (Level 1) or SAQ (Levels 2–4)
+- Signed by both the organisation's officer and the QSA (for ROC) or responsible officer (for SAQ)
+- Submitted annually to the acquiring bank or card brand
+- A merchant-specific or service provider-specific version exists
+
+---
+
+## Approved Scanning Vendor (ASV) Scans
+
+Quarterly external vulnerability scans by an ASV are required for all merchants and service providers. An ASV is a company approved by PCI SSC to perform external network vulnerability scanning services.
+
+- Scans must result in a **passing scan** (no unresolved high-severity vulnerabilities)
+- If a scan fails, remediate and re-scan until a passing result is achieved
+- Passing scan reports must be retained for compliance evidence
+- Internal scans (Req 11.3.1) may be performed by internal staff
+
+---
+
+## Qualified Security Assessor (QSA) vs Internal Security Assessor (ISA)
+
+| Role | Who | Used For |
+|------|-----|---------|
+| **QSA** | External PCI SSC-approved company | Required for ROC (Level 1); optional for SAQs to guide/verify |
+| **ISA** | Internal employee trained and certified by PCI SSC | Can perform internal assessments; cannot sign ROC for Level 1 |
+
+ISAs are useful for ongoing internal compliance monitoring and SAQ validation for Levels 2–4.