PCI Compliance Dashboard

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €19/mo; support commitment: PCI audit documentation, SSL monitoring

Generated from docs/plan/paid/pci-compliance-dashboard/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid service that monitors PCI DSS compliance status, generates attestation documents proving that the shop never stores card data, maintains SSL certificates, and provides documentation for annual PCI audits. Merchants reduce audit costs and pass inspections without struggle.

The problem

A Spanish merchant’s annual PCI audit costs €1500 and takes 2 weeks. The audit firm asks her to prove: (1) card data is never stored, (2) SSL is current, (3) logging is secure. She has no centralized documentation. She manually gathers evidence, often missing something, and the audit fails. She wants to prove PCI compliance quickly.

What it does

• PCI architecture proof: document that card data is never stored on AstroBaaS (payment gateway handles it)
• SSL certificate monitoring: verify shop’s HTTPS certificate is valid, alert before expiry
• PCI attestation document: auto-generated PDF for annual audit, includes compliance evidence
• Logging security: document that logs are stored securely, access controlled, not publicly exposed
• Vulnerability scanning: periodic security scans, results included in attestation
• Staff access log: track which staff accessed payment-related data (none, in theory)
• Payment gateway integration proof: document that card data flows through payment gateway, never touches AstroBaaS servers
• Network segmentation proof: show that payment systems are isolated from other systems
• Audit history: merchant can view past audit documents (for historical compliance proof)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Actual PCI audit (third-party handles this)—we provide documentation only
• Penetration testing—out of scope; external firm does this
• Compliance enforcement (we don’t prevent merchants from storing cards)—merchant responsibility
• Payment gateway selection—merchant chooses; we just document their choice
• Network security (firewalls, DDoS protection)—infrastructure handles

Data model

New: PCIAttestation(id, shopId, generated_at, ssl_cert_valid_until, vulnerability_scan_results_json, architecture_document_url). Stored in plugin settings, no core migration.

API

• GET /pci/status — return current PCI compliance status (green/yellow/red)
• GET /pci/attestation/latest — return most recent attestation document
• POST /pci/attestation/generate — generate new attestation PDF
• GET /pci/ssl-certificate — return SSL certificate validity status
• POST /pci/vulnerability-scan — trigger security scan (optional)
• GET /pci/audit-history — list all past attestations

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

PCI compliance dashboard: current status (green=compliant), SSL certificate expiry (red if <30 days), last vulnerability scan date, attestation document (download PDF), audit history (past attestations), security checklist

The seam — why this is paid

Core owns: documentation that card data is never stored, logging access. Paid pack owns: SSL monitoring credential, vulnerability scanning tool integration, attestation PDF generation, support for audit interpretation.

Support commitment: PCI attestation support, SSL certificate monitoring

Dependencies

• payment gateway integration (must document that cards go through gateway, never touch core systems)
• email layer (to alert on SSL expiry)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• PCI status dashboard shows ‘Compliant’ (green) when SSL is valid, no open vulnerabilities
• SSL certificate expiry is <30 days; dashboard shows red ‘Certificate expires soon’ alert
• Generating attestation PDF produces a document with sections: Architecture (cards via gateway), Logging (access-controlled), SSL (current), Vulnerabilities (scan date, findings)
• Attestation PDF can be handed to auditor without redaction (all sensitive details removed)
• SSL certificate check runs daily; expiry alert is sent 30 days before expiration
• Audit history shows attestations generated in Jan, Apr, Jul, Oct (quarterly)
• Vulnerability scan results are embedded in attestation (e.g., ‘No critical vulnerabilities found’)
• Disabling SSL (hypothetically) immediately marks PCI status as ‘Non-Compliant’ (red)

Risks

If SSL certificate expires and we don’t alert, merchant is non-compliant and doesn’t know—must have proactive alerts. Attestation PDF becomes stale (vulnerable tomorrow)—must clarify it’s a point-in-time snapshot. Auditor rejects our attestation format—must align with PCI guidelines. If we claim ‘no vulnerabilities’ but one is found later, merchant’s liability increases.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.