# PCI DSS readiness — twelve requirements, the evidence and the road to assessment Recipe No. 36, Work and teams. From The know.sh Cookbook: https://know.sh/cookbook/pci-dss-tracking Walk into the assessment with the answers filed: a document per requirement with its controls, status and owner by role, evidence moving from requested to reviewed, a Gantt chart to the assessor’s visit, and every scope decision and compensating control written down with its reason. - For: a compliance lead getting a small company ready for PCI DSS - You get: a document per requirement, evidence on a board, a plan to the QSA - Time: a day to set up, an hour a week - Made with: Shelf, Document, Section, Elements, Your AI assistant, Revisions ## How it works 1. **A document per requirement.** Ask your assistant for a shelf with one document per PCI DSS v4.0.1 requirement, one section per control you must meet, each with its owner by role and status. 2. **Track evidence on a board.** In each document, ask for a table element of the controls and a kanban element of evidence: to collect, collected, reviewed. Never paste card data or live secrets. 3. **Plan back from the assessment.** Give the assessor’s dates and ask for a Gantt chart: remediation, evidence, the penetration test and the readiness review, with the fixed dates marked critical. 4. **Record every scope decision.** Each time you shrink scope or rely on a compensating control, ask for a decisions entry with the reason. Your QSA reads the same register. ## Try this prompt Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > On my know.sh shelf PCI DSS 2027, make one document per PCI DSS v4.0.1 principal requirement, titled with its number and name. In each, add a status section with a table element (requirement number, control, status, owner by role) and a kanban element of evidence: to collect, collected, reviewed. Use roles, never names, and file anything you are unsure applies to us as a Question. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Add a decisions entry to the scope register in my readiness document: box-office kiosks past vendor support, a compensating control for 6.3.3 until May 2027, with the controls I listed and the replacement as the alternative. Then mark kiosk isolation on the Gantt chart. ## Elements in the specimens Written as your assistant writes them through the know.sh MCP server. Each reads as plain words until you turn elements on (Account → Elements). Heatmap, specimen 1: ```element heatmap { "caption": "Controls in place by requirement, per cent, May to September", "rowTitle": "Requirement", "columnTitle": "Month", "columns": [ { "label": "May" }, { "label": "Jun" }, { "label": "Jul" }, { "label": "Aug" }, { "label": "Sep" } ], "rows": [ { "label": "1 Network security controls", "values": "40, 55, 70, 85, 90" }, { "label": "2 Secure configurations", "values": "30, 45, 60, 70, 80" }, { "label": "3 Protect stored account data", "values": "60, 80, 95, 100, 100" }, { "label": "4 Cryptography in transit", "values": "70, 80, 90, 100, 100" }, { "label": "5 Malicious software", "values": "50, 60, 75, 80, 85" }, { "label": "6 Secure systems and software", "values": "20, 30, 45, 55, 65" }, { "label": "7 Access by need to know", "values": "45, 55, 65, 75, 85" }, { "label": "8 Identify and authenticate", "values": "25, 40, 50, 60, 70" }, { "label": "9 Physical access", "values": "80, 85, 90, 95, 100" }, { "label": "10 Log and monitor", "values": "20, 30, 40, 55, 60" }, { "label": "11 Test security regularly", "values": "15, 25, 35, 45, 55" }, { "label": "12 Policies and programmes", "values": "35, 45, 60, 70, 80" } ], "units": "%", "steps": 5, "range": "zero", "source": "Share of each requirement’s applicable controls marked *In place* in its document, at month end." } ``` Gantt chart, specimen 1: ```element gantt { "caption": "From remediation to the assessor’s visit", "description": "Scope was confirmed on 7 September. Multi-factor authentication into the cardholder data environment runs six weeks from 21 September and is critical. The payment-page script inventory runs five weeks from 14 September; log alerting five weeks from 5 October; the kiosk compensating control three weeks from 12 October. Evidence collection runs from 1 October to 15 January. Penetration tests run two weeks from 16 November, the readiness review with the QSA is the week of 7 December, and the on-site assessment is 8 to 10 February 2027, critical.", "width": "wide", "dateFormat": "YYYY-MM-DD", "sections": [ { "id": "fix", "label": "Remediation" }, { "id": "prove", "label": "Evidence" }, { "id": "assess", "label": "Assessment" } ], "tasks": [ { "id": "scope", "label": "Scope confirmed", "section": "fix", "shape": "milestone", "start": "2026-09-07", "duration": "0d", "status": "done" }, { "id": "mfa", "label": "MFA into the CDE", "section": "fix", "shape": "bar", "start": "2026-09-21", "duration": "6w", "status": "active", "critical": true }, { "id": "scripts", "label": "Payment-page scripts", "section": "fix", "shape": "bar", "start": "2026-09-14", "duration": "5w", "status": "active" }, { "id": "logs", "label": "Log alerting", "section": "fix", "shape": "bar", "start": "2026-10-05", "duration": "5w" }, { "id": "kiosk", "label": "Kiosk isolation", "section": "fix", "shape": "bar", "start": "2026-10-12", "duration": "3w" }, { "id": "evidence", "label": "Collect evidence", "section": "prove", "shape": "bar", "start": "2026-10-01", "end": "2027-01-15" }, { "id": "pentest", "label": "Penetration tests", "section": "prove", "shape": "bar", "start": "2026-11-16", "duration": "2w" }, { "id": "ready", "label": "Readiness review", "section": "assess", "shape": "bar", "start": "2026-12-07", "duration": "1w" }, { "id": "onsite", "label": "QSA on site", "section": "assess", "shape": "bar", "start": "2027-02-08", "duration": "3d" } ], "axisFormat": "%b", "tickInterval": "1month", "weekStart": "monday", "weekend": "saturday", "today": "shown" } ``` Table, specimen 2: ```element table { "caption": "Requirement 8, the controls we track", "columns": [ { "label": "Requirement", "align": "left" }, { "label": "Status", "align": "left" }, { "label": "Owner", "align": "left" } ], "rows": [ [ "8.2.1 A unique ID for every user", "In place", "IT lead" ], [ "8.2.2 Shared accounts only by documented exception", "In place", "IT lead" ], [ "8.2.6 Inactive accounts removed or disabled within 90 days", "In place", "IT lead" ], [ "8.3.6 Passwords of at least 12 characters", "Partial", "IT lead" ], [ "8.4.2 MFA for all access into the CDE", "Gap", "Engineering" ], [ "8.4.3 MFA for remote network access", "In place", "IT lead" ], [ "8.6.1 Interactive use of system accounts controlled", "Gap", "Engineering" ] ], "notes": "8.3.6, 8.4.2 and 8.6.1 were future-dated in v4.0 and have applied since 31 March 2025." } ``` Kanban board, specimen 2: ```element kanban { "caption": "Requirement 8 evidence, week of 21 September", "description": "To collect: jump host MFA settings for 8.4.2, high priority; the system account inventory for 8.6.1; the box-office password settings for 8.3.6. Collected: the user list for CDE systems, 8.2.1; the leavers report against access removals, 8.2.5. Reviewed: the VPN MFA settings, 8.4.3, and the inactive-account job log, 8.2.6.", "columns": [ { "label": "To collect", "cards": [ { "label": "Jump host MFA settings", "ticket": "8.4.2", "assigned": "Engineering", "priority": "high" }, { "label": "System account inventory", "ticket": "8.6.1", "assigned": "Engineering" }, { "label": "Box-office password settings", "ticket": "8.3.6", "assigned": "IT lead" } ] }, { "label": "Collected", "cards": [ { "label": "User list, CDE systems", "ticket": "8.2.1", "assigned": "IT lead" }, { "label": "Leavers against removals", "ticket": "8.2.5", "assigned": "IT lead" } ] }, { "label": "Reviewed", "cards": [ { "label": "VPN MFA settings", "ticket": "8.4.3", "assigned": "IT lead" }, { "label": "Inactive-account job log", "ticket": "8.2.6", "assigned": "IT lead" } ] } ] } ``` Decisions, specimen 3: ```element decisions { "caption": "Scope decisions and compensating controls", "decisions": [ { "title": "Card numbers in the order database", "status": "decided", "date": "2026-07-14", "choice": "Store the processor’s tokens only; purge every stored card number", "reason": "Takes the order database and its backups out of the cardholder data environment, and most of Requirement 3 with it.", "alternatives": [ { "option": "Keep them, encrypted at rest" } ] }, { "title": "Phone bookings", "status": "decided", "date": "2026-08-03", "choice": "Keypad entry masked by the telephony provider", "reason": "Agents never hear or key a card number, so their desktops and the call recordings stay out of scope.", "alternatives": [ { "option": "Agents key cards into a virtual terminal" } ] }, { "title": "Box-office kiosks past vendor support", "status": "decided", "date": "2026-09-07", "choice": "A compensating control for 6.3.3 until replacement in May 2027", "reason": "Replacements have a 16-week lead time. Kiosks move to their own network segment with application allow-listing and daily file-integrity checks, written up in the Appendix C worksheet.", "alternatives": [ { "option": "Replace them before the assessment" } ] }, { "title": "Customized approach", "status": "decided", "date": "2026-07-14", "choice": "The defined approach for every requirement", "reason": "Our first assessment under v4.0.1; a customized control needs its own targeted risk analysis and more of the assessor’s time." }, { "title": "Payment-page scripts, 6.4.3 and 11.6.1", "status": "open", "choice": "A script-monitoring service on the checkout page", "reason": "Decide after the readiness review in December.", "alternatives": [ { "option": "A strict Content Security Policy with reporting" } ] } ] } ```