Loading…
Trust · PCI-DSS
PCI-DSS (Payment Card Industry Data Security Standard) is the contractual security standard cardholder-data handlers must meet, governing storage, processing, and transmission of cardholder and authentication data across people, process, and technology controls.
What it is, what it covers
Payments-touching systems have a binary outcome: either the cardholder-data flow is scoped, isolated, and audit-defensible, or the entire connected estate is in scope. Prosigns engineers payments systems with the second outcome treated as a defect — every architecture decision narrows scope, and every control produces evidence as a side effect of normal operation.
Our security department CITADEL co-pilots payments engagements from kickoff. Threat models, network segmentation, key management, and audit-trail design land in the architecture phase, not in a remediation cycle two weeks before a QSA walkthrough. The engineering we ship is supportable on QSA evidence pulls without scrambling.
Prosigns is not itself a PCI-DSS Level 1 service provider — we don't process cardholder data on Prosigns infrastructure. We engineer and operate systems where you do, with tokenization-first architectures that move PAN data to PCI-Validated processors and keep your application out of cardholder-data scope wherever the design permits.
Scope
PCI-DSS applies to any merchant or service provider that stores, processes, or transmits cardholder data. The standard scales by transaction volume — Levels 1-4 — but the technical requirements are uniform. Engagements with payments-touching deliverables are scoped against the standard from the first architecture review.
Engineering controls
Prosigns engineering practices that produce PCI-DSS-aligned evidence as a side-effect of normal delivery. Each control carries a specific reference where applicable.
We default to tokenization at the entry point — PAN data is exchanged for tokens via a PCI-Validated processor before it touches application logic. The token surface narrows the in-scope estate to the integration boundary, taking the application code out of cardholder-data scope wherever business logic permits.
PCI-DSS v4.0 Req. 3 (Protect stored cardholder data)
Cardholder Data Environment (CDE) is isolated at the network layer with explicit ingress/egress rules, segmentation tested annually, and traffic flows documented in network diagrams that match the actual VPC / subnet configuration. We treat 'segmentation drift' between documented topology and runtime configuration as an audit-blocking defect.
PCI-DSS v4.0 Req. 1 (Network security controls)
TLS 1.2+ enforced on every endpoint. Stored cardholder data, when unavoidable, encrypted at rest with customer-managed keys (KMS) and documented key-rotation cadence. Key-access events are logged to immutable audit trails the QSA can pull on demand.
PCI-DSS v4.0 Req. 3, 4 (Protect cardholder data, Encrypt transmission)
MFA enforced for all admin access to CDE components. Role-based access reviewed quarterly; just-in-time access via short-lived credentials for production sessions. Service-account credential rotation automated on a documented cadence; every privileged action carries actor identity in the audit trail.
PCI-DSS v4.0 Req. 7, 8 (Restrict access, Identify and authenticate)
Application, infrastructure, and access logs centralized into an audit-grade store with at least 12 months of retention (3 months immediately accessible). Log integrity protected against tampering; alerting on anomalous events tied to the incident-response runbook.
PCI-DSS v4.0 Req. 10 (Log and monitor all access)
Every pull request to CDE-adjacent code goes through senior code review, SAST in CI, and dependency scanning. DAST runs against staging on every release candidate. Vulnerability disposition is documented; risk-accepted findings are tracked with explicit owner, mitigation, and review date.
PCI-DSS v4.0 Req. 6 (Develop and maintain secure systems)
Documented incident-response procedures with named roles, communication paths, and 72-hour customer-notification flows. Tabletop exercises run quarterly; post-incident reviews land in the runbook so the next response is faster than the last.
PCI-DSS v4.0 Req. 12 (Maintain an information security policy)
Control activity logs, change records, access reviews, vulnerability scans, and policy attestations are produced as a side-effect of operating the system, not assembled in a panic two weeks before exam. Audit pulls run in days, not weeks.
Honest posture
Prosigns engineering practices are PCI-DSS-aligned and CITADEL-co-piloted on every payments-touching engagement. We are not ourselves a PCI-DSS Level 1 service provider; we engineer and operate systems where you are. AOCs are engagement-scoped to the deliverable.
Audit pack contents
Engagement-scoped to the PCI-DSS deliverable. Available on request under NDA, same business day for procurement and InfoSec review.
Where it applies
Services we deliver
Payments-touching enterprise apps with scope-minimized cardholder-data architecture.
Open the practiceNetwork segmentation, CDE design, and PCI-aware multi-account topology.
Open the practiceThreat modeling, secure SDLC, and key-management discipline for payments scope.
Open the practiceFrequently asked
Prosigns is not itself a PCI-DSS Level 1 service provider — we don't store, process, or transmit cardholder data on Prosigns infrastructure. We engineer and operate systems where you do, aligned to the standard's technical requirements. CITADEL co-pilots every payments-touching engagement; the architecture is QSA-supportable on evidence pulls.
Tokenization-first architecture is the default. We design the integration so PAN data is exchanged for tokens at the earliest entry point via a PCI-Validated processor, taking the bulk of application code out of cardholder-data scope. Network segmentation with documented CDE boundaries narrows the in-scope estate further; the goal is that the scoped surface matches the QSA walkthrough verbatim.
Architecture and data-flow diagrams, network segmentation map, threat model, tokenization integration design, key-management policy, access-control matrix, SAST/DAST/dependency-scanning configuration and results, incident-response runbook, and the engagement-scoped Attestation of Compliance where applicable. Available under NDA in under one business day for procurement and InfoSec.
Yes. MFA is enforced for all admin access into CDE components and for all access into systems that store, process, or transmit cardholder data. Role-based access is reviewed quarterly; just-in-time access via short-lived credentials is the default for production sessions. The control evidence is collected as a side-effect of normal operation, not as audit-time scrambling.
Schrems II is a GDPR concern, not strictly PCI, but the architectures overlap. We design payments systems with explicit data-residency boundaries — region-aware processing, Standard Contractual Clauses (SCCs) where applicable, and subprocessor governance documented in the DPA. Cross-border PAN flows are minimized; tokenization moves the heavy lifting onto PCI-Validated processors with their own audited residency posture.
On engagements where Prosigns is the system integrator, we coordinate with your nominated QSA on architecture review, evidence pulls, and remediation cycles. We don't substitute for your QSA — the assessment relationship is yours — but we make their job straightforward by producing the evidence in the form they expect.
PCI-DSS-aligned engineering doesn't carry a separate line item — it's how we engineer payments-touching systems by default. The incremental cost is the architecture rigor (more design time up front, more evidence-collection plumbing) which typically lands within a 5-10% premium over a non-regulated equivalent and pays back in the first audit cycle.
Related regulators
Sarbanes-Oxley Act of 2002
SOX 404 IT General Controls for Financial-Reporting Systems
Open the pageNew York State Department of Financial Services (DFS)
NYDFS 23 NYCRR 500 Cybersecurity for Financial Institutions
Open the pageU.S. Department of Health & Human Services (HHS)
HIPAA / HITECH Engineering for Healthcare Workloads
Open the pageTalk to us
CITADEL co-pilots every regulated engagement. Senior engineer plus department lead joins the first call. Audit pack on the same business day.