Commerce Security and Compliance Checklist

Summary

A PCI certificate doesn't mean a commerce platform is secure. This checklist covers what actually matters, from data handling practices to third-party risk, so you can identify real exposure before it becomes a client problem.

Compliance Checkboxes Miss What Actually Causes Breaches

Most commerce security assessments follow a predictable script: confirm PCI compliance, check for SSL, move on. That approach misses the gaps that actually cause breaches.

Modern commerce architectures involve dozens of integrations, multiple data processors, and distributed access controls. A platform can be technically PCI compliant while still exposing customer data through a poorly configured third-party integration or an over-permissioned admin account.

This checklist is designed for agencies and consultants conducting security assessments during discovery, replatforming due diligence, or ongoing advisory work. The questions surface real issues, not just confirm that someone thought about security at some point.

PCI DSS: Define the Real Scope, Not the Convenient One

Cardholder Data Environment

Where does cardholder data enter the environment, and is that entry point documented?
What systems touch cardholder data between entry and transmission to the payment processor?
Has the CDE scope been formally defined and reviewed in the last 12 months?
Are there any systems that were excluded from scope, and what was the justification?

Tokenization and Encryption

At what point is cardholder data tokenized, and who controls the token vault?
Is the tokenization solution PCI-certified, or is it a custom implementation?
What encryption standards are applied to data at rest, and when were keys last rotated?
Can any internal system or user access full card numbers after tokenization?

Compliance Documentation

When was the last SAQ or ROC completed, and what level applies?
Who is the designated PCI compliance owner internally?
Are there any open remediation items from the last assessment?
Has there been any scope change (new integrations, infrastructure changes) since the last attestation?

Data Handling: Know Where Customer Data Actually Lives

Customer Data Inventory

Is there a documented inventory of all customer PII collected, stored, and processed?
Where does customer data reside, and does it cross regional boundaries?
What data is retained post-transaction, and what is the retention policy?
Can customer data be fully deleted on request, and has this been tested?

Consent and Regulatory Compliance

How is consent captured for marketing communications, and is it auditable?
Are there separate consent mechanisms for different data uses (analytics, personalization, remarketing)?
What GDPR or CCPA controls are in place, and have they been validated by legal?
How are data subject access requests (DSARs) handled operationally?

Data Sharing and Processing

Which third parties receive customer data, and under what agreements?
Are data processing agreements (DPAs) in place with all vendors handling PII?
How is customer data anonymized or pseudonymized for analytics purposes?
Is there a process to audit third-party data handling practices?

Access Controls: Assume Permissions Have Drifted

User Access

What access control model is used (RBAC, ABAC, or ad hoc)?
How many users have admin-level access to the commerce platform?
When was admin access last audited, and were any unnecessary privileges found?
Are there shared accounts or service accounts with broad permissions?

Authentication

Is multi-factor authentication enforced for all admin and backend access?
What MFA methods are supported, and are any weaker options (SMS) still enabled?
How are API keys and service credentials managed and rotated?
Are there any legacy systems that bypass the primary authentication mechanism?

Access Lifecycle

What is the process for provisioning access for new team members or vendors?
How quickly is access revoked when someone leaves the organization or project?
Is there an audit log of access changes, and who reviews it?
Are contractor and agency accounts treated differently from internal accounts?

Third-Party Risk: Your Weakest Vendor Is Your Weakest Link

Vendor Inventory

Is there a complete inventory of all third-party scripts, integrations, and services?
Which third parties have access to production systems or customer data?
Are vendors categorized by risk level based on data access and criticality?
When were vendor security practices last reviewed?

Integration Security

How are API credentials shared with third parties, and who controls rotation?
Are third-party integrations sandboxed or do they have broad system access?
What monitoring exists for third-party API calls and data access?
Has any third party been sunset but not fully removed from the environment?

Contractual Requirements

Do vendor contracts include security requirements and breach notification terms?
Are third parties required to maintain their own compliance certifications?
Is there a process to reassess vendors when their service scope changes?
What happens if a critical vendor fails a security audit?

Infrastructure and Application: Check the Boring Stuff

Platform Configuration

Has the commerce platform been hardened according to vendor security guidelines?
Are default credentials, sample data, or test configurations removed from production?
What logging and monitoring is enabled at the platform level?
How are security patches applied, and what is the typical lag time?

Application Security

When was the last penetration test conducted, and what was the scope?
Are there open vulnerabilities from previous security assessments?
Is there a web application firewall (WAF) in place, and how is it configured?
How are custom code changes reviewed for security before deployment?

Infrastructure

Who has access to production infrastructure (servers, databases, cloud console)?
Are production environments isolated from development and staging?
What DDoS protection and rate limiting is in place?
How is infrastructure access logged and audited?

Incident Response: Plan for When, Not If

Incident Response

Is there a documented incident response plan specific to commerce and data breaches?
Who is responsible for incident response, and is there 24/7 coverage?
When was the incident response plan last tested?
What are the notification requirements if customer data is exposed?

Backup and Recovery

What is the backup frequency for commerce data, and where are backups stored?
Has a full restore from backup been tested, and what was the recovery time?
Are backups encrypted and protected with separate access controls?
What is the recovery point objective (RPO) and recovery time objective (RTO)?

Business Continuity

What is the failover plan if the primary commerce platform goes down?
Are there dependencies on single points of failure (one payment processor, one CDN)?
How are customers and stakeholders notified during an outage?

Turn Findings Into Decisions

This checklist produces findings, not checkboxes. Document:

Current state, What controls exist today, and where are the gaps?
Risk assessment, Which gaps represent real exposure versus theoretical concerns?
Remediation priorities, What must be fixed before launch, and what can be addressed post-launch with a defined timeline?

Group findings by severity and effort. Some issues require immediate action (exposed credentials, missing MFA). Others are process improvements that can be roadmapped (vendor review cadence, access audit frequency).

Access control issues often trace back to unclear stakeholder roles. Compliance gaps frequently stem from undocumented integrations. Security is a lens on the same system you're already mapping, not a separate workstream.

How DigitalStack Connects Security to Everything Else

In DigitalStack, security findings link directly to system architecture, stakeholder responsibilities, and project requirements. When you identify a third-party risk, it connects to the integration inventory. When you document access control gaps, it ties to the stakeholder map.

Remediation items become tracked requirements. Compliance status becomes part of architecture documentation. Nothing lives in a disconnected spreadsheet that gets forgotten after the audit.

Next Step

Structure your next security assessment inside DigitalStack. Keep findings connected to systems, stakeholders, and requirements, so compliance work drives decisions instead of generating static reports.