PCI DSS Overview
This guide is part of the documentation available in SecBoard. It explains what the Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, and how SecBoard modules help you implement and demonstrate compliance with PCI DSS requirements and controls. Use SecBoard Framework Compliance to map controls to PCI DSS, attach evidence, and track status; use SecBoard PCI DSS Standard (app_std) for requirement text and categories; and use other SecBoard modules for assets, access, logging, incidents, policies, training, service providers, and data protection.
What is PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) is a global standard for protecting cardholder data (e.g. card number, expiry, CVV) and the cardholder data environment (CDE). It applies to organisations that store, process, or transmit cardholder data or that can affect the security of that data. Compliance is required by card brands and acquirers; non-compliance can lead to fines, restrictions, or loss of ability to process cards.
PCI DSS is organised around 12 requirements grouped into 6 goals: secure network and systems, protect account data, vulnerability management, strong access control, monitor and test networks, and maintain an information security policy. The standard evolves (e.g. PCI DSS 4.0); your compliance programme should track the version and scope (systems and processes in scope for PCI DSS).
The six goals and twelve requirements
Understanding the structure helps you assign ownership and map evidence in SecBoard.
Req 1: Install and maintain network security controls (e.g. firewalls, network segmentation).
Req 2: Apply secure configurations to all system components (defaults changed, hardening).
Req 3: Protect stored account data (minimise storage, encrypt, key management).
Req 4: Protect cardholder data with strong cryptography during transmission (e.g. TLS, no weak protocols).
Req 5: Protect systems and networks from malicious software (anti-malware, policies).
Req 6: Develop and maintain secure systems and software (secure SDLC, patches, change management).
Req 7: Restrict access to system components and cardholder data by business need to know.
Req 8: Identify users and authenticate access (unique IDs, MFA, password policy).
Req 9: Restrict physical access to cardholder data and systems.
Req 10: Log and monitor all access to system components and cardholder data.
Req 11: Test security of systems and networks regularly (vulnerability scans, penetration tests).
Req 12: Support information security with organisational policies and programmes (policy, risk assessment, awareness, incident response).
How SecBoard modules support PCI DSS
SecBoard does not replace technical controls (firewalls, encryption, IdP), but it helps you manage scope, map requirements to controls, collect evidence, and track compliance. Use the modules below in line with your PCI DSS scope and assessor expectations.
| SecBoard module | PCI DSS area | How it helps |
|---|---|---|
| Framework Compliance | All goals (controls, evidence, status) | Create a PCI DSS framework (framework_type = PCI DSS), define control categories and controls aligned to the 12 requirements, attach evidence (documents, links), assign owners and review dates. Use for gap analysis, audit preparation, and tracking implementation status. Dashboard shows compliance status (e.g. traffic light by framework). |
| PCI DSS Standard (app_std) | Requirements, categories, documentation | Store and browse PCI DSS requirement text and categories (PCIDSSCategory, PCIDSSRequirement). Attach PCI DSS documents (PCIDSSDocument). Use AI/search to find requirements by topic. Access controlled by AccessPCIDSS (groups). Supports requirement-level reference when mapping controls in Framework Compliance or Risk. |
| Risk Assessment (app_risk) | Req 12 (risk assessment) | Perform and document risk assessments. Link risks to PCI DSS requirement (pci_dss_requirement field where available). Use for annual risk assessment and risk-based prioritisation of PCI DSS controls. Evidence can be linked to Framework Compliance controls. |
| Incident Register (app_incident) | Req 12 (incident response) | Record and manage security incidents (including cardholder data compromise, breaches, malware). Document response, containment, and lessons learned. Use for incident response programme evidence and for post-incident reviews required by PCI DSS. |
| Asset management (app_asset) | Req 2, 12 (in-scope systems, inventory) | Maintain inventory of in-scope system components and data flows. Document asset ownership, classification, and location. Use for scope definition and for secure configuration (Req 2) and policy (Req 12) evidence. Asset Guide available for user guidance. |
| Keys & Certificates (app_keycert) | Req 3, 4 (cryptography, keys, TLS) | Manage cryptographic keys and certificates used to protect stored and transmitted cardholder data. Track issuance, expiry, and usage. Use for key management and certificate lifecycle evidence (Req 3.5, 3.6, 4.2.1). Key/Cert Guide available. |
| Document Register / Legislative docs (app_doc) | Req 12 (policies, procedures) | Store and version security policies, procedures, and standards (e.g. access control policy, incident response procedure, acceptable use). Link documents to Framework Compliance evidence. Use Reg Docs and Related Docs for policy evidence; Mandatory Processes for recurring procedures. |
| Cabinet (app_cabinet) | Req 7, 8 (access, users, groups) | Manage users and groups, assign permissions and company scope. Supports need-to-know (Req 7) and unique identification (Req 8). Enforce MFA and strong passwords at IdP/app level; use Cabinet to keep access rights accurate. Cabinet Users Guide and Org Structure Guide support user/access documentation. |
| SOC / Wazuh (app_soc) | Req 10, 11 (logging, monitoring, testing) | Centralise logs, monitor access and changes (e.g. FIM), detect anomalies. Use for log management (Req 10) and for supporting vulnerability and integrity monitoring (Req 11). FIM Dashboard Guide explains Wazuh-based monitoring. Evidence (e.g. screenshots, reports) can be attached in Framework Compliance. |
| Gophish (app_gophish) | Req 12 (awareness, testing) | Run phishing simulations and security awareness campaigns. Use for security awareness programme (Req 12.6) and to test user behaviour. Gophish Guide explains phishing and SecBoard Gophish. Results can inform training and be referenced in compliance evidence. |
| Study / Training (app_study) | Req 12 (awareness, password policy) | Deliver and track security awareness training. Password policy validation (e.g. validate_password_pci_dss) supports Req 8.2 (strong passwords). Use for training records and awareness programme evidence. |
| Access (app_access) | Req 7, 8 (access control, authentication) | Manage access to applications and resources. Use with Cabinet to enforce least privilege and need-to-know. Combine with MFA and logging for Req 7 and 8 evidence. |
| TPRM (app_tprm) | Req 12 (service provider management) | Manage vendors and service providers that store, process, or transmit cardholder data or can affect the CDE. Use Vendor inventory, VendorAssessment, and VendorQuestionnaire to document due diligence and compliance; attach VendorDocument for contracts and attestations. Supports PCI DSS requirements for maintaining a list of service providers and ensuring agreements and compliance are in place. Evidence can be linked to Framework Compliance controls for Req 12. |
| GDPR (app_gdpr) | Req 3, 12 (data protection, retention, breach) | Where cardholder data is personal data, align with data protection obligations. Use Data Processing Activities for processing inventory and lawful basis; Data Retention Policy for retention and minimisation (supports Req 3); DataBreachIncident for breach detection, reporting, and response (supports Req 12 incident response). DPIA and Data Subject Requests support privacy-by-design and individual rights. Link evidence to Framework Compliance where PCI DSS and GDPR controls overlap. |
| Configuration (app_conf) | Company, scope, multi-tenant | Define companies and configuration. Use to scope PCI DSS by company (e.g. which companies/entities are in scope) and to align Framework Compliance instances to the right entity. |
Quick mapping: requirement → SecBoard
| Req | SecBoard modules to use |
|---|---|
| 1, 2 | Framework Compliance (controls/evidence), Asset (in-scope systems), Document Register (config standards). |
| 3, 4 | Framework Compliance, Keys & Certificates (keys, certs, TLS), Document Register (crypto policy), GDPR (retention, data processing activities). |
| 5, 6 | Framework Compliance, SOC (monitoring, FIM), Document Register (anti-malware, SDLC policies), Incident (security events). |
| 7, 8, 9 | Framework Compliance, Cabinet (users, groups, access), Access, Study (password policy, training), Document Register (access policy). |
| 10, 11 | Framework Compliance, SOC (logs, monitoring, FIM), Incident (incident response), Document Register (logging/test procedures). |
| 12 | Framework Compliance, Risk Assessment, Incident Register, Document Register (policies, procedures), Gophish, Study (awareness), Mandatory Processes, TPRM (service providers), GDPR (breach management, retention, processing activities). |
Getting started with PCI DSS in SecBoard
- Define scope: Use Asset management and Configuration to document in-scope systems and companies. Create a PCI DSS framework in Framework Compliance (framework_type = PCI DSS, version e.g. 4.0).
- Map controls: In Framework Compliance, create control categories and controls for each of the 12 requirements (or sub-requirements). Use PCI DSS Standard (app_std) to copy or reference requirement text.
- Collect evidence: Attach documents from Document Register, links to SOC dashboards or Key/Cert data, and references to Incident or Risk. Use TPRM for service provider list, assessments, and contracts; use GDPR for data processing activities, retention policies, and breach handling where cardholder data is personal data.
- Access and policies: Use Cabinet and Access to enforce need-to-know and unique IDs; use Study for password policy and awareness. Store policies in Document Register and link to controls.
- Monitor and test: Use SOC for logging and monitoring; run and document scans and tests, and attach evidence to Req 10 and 11 controls. Use Gophish and Study for awareness and testing.
- Review: Use the Framework Compliance dashboard and traffic light (e.g. Cabinet dashboard) to track status. Revisit scope and controls periodically and before assessments.
PCI DSS and SecBoard
This guide is part of the documentation available in SecBoard. Use SecBoard Framework Compliance to map PCI DSS requirements to controls and evidence; use SecBoard PCI DSS Standard (app_std) for requirement and category reference; and use Asset, Keys & Certificates, Document Register, Cabinet, SOC, Incident Register, Risk Assessment, Gophish, Study, TPRM, and GDPR to support the 12 requirements and 6 goals. The Framework Compliance dashboard and Cabinet compliance traffic light (PCI DSS, ISO 27002, GDPR, etc.) help you track status across frameworks.
Align scope, controls, and evidence with your PCI DSS version and assessor expectations, and keep documentation and access rights up to date for a sustainable compliance programme.
Frequently asked questions
What is PCI DSS? — The Payment Card Industry Data Security Standard: a set of 12 requirements (in 6 goals) for protecting cardholder data and the cardholder data environment. It applies to organisations that store, process, or transmit card data or that can affect its security.
Which SecBoard module do I use for PCI DSS requirements text? — Use SecBoard PCI DSS Standard (app_std): PCIDSSCategory and PCIDSSRequirement for requirement and category text; PCIDSSDocument for attached documents. Access is controlled by AccessPCIDSS.
How do I demonstrate compliance? — In SecBoard Framework Compliance, create a framework with type PCI DSS, add controls per requirement, and attach evidence (documents from Document Register, links to SOC/Key Cert, references to incidents or risk assessments). Use the dashboard and status to track progress.
Which modules support Req 10 and 11? — SOC (app_soc) for logging, monitoring, and FIM; Incident Register for response; Document Register for procedures. Attach screenshots or reports as evidence in Framework Compliance.
How do I support Req 12 (policies, risk, awareness, incidents)? — Use Document Register for policies and procedures, Risk Assessment for risk assessment, Incident Register for incident response, Gophish and Study for awareness and training, TPRM for service provider management, and GDPR for breach management and data protection where applicable. Link evidence to the Req 12 controls in Framework Compliance.
How do TPRM and GDPR support PCI DSS? — TPRM (app_tprm) supports Req 12 service provider management: maintain vendor list, conduct assessments and questionnaires, store contracts and attestations. GDPR (app_gdpr) supports Req 3 (retention, minimisation via Data Retention Policy and processing activities) and Req 12 (breach response via DataBreachIncident); where cardholder data is personal data, use both frameworks together and link evidence in Framework Compliance.