Considerations for PCI-DSS Compliant Solution Development — Part 1

Building software that operates in a PCI-DSS compliant environment goes well beyond writing secure code. It requires deliberate decisions at every layer—from how you manage patches and passwords, to how you separate your environments and handle test data. This post covers the first nine considerations every development team should address.

1. Keep security patches current

All vendor-supplied security patches must be kept up to date. Critical security patches must be installed within one month of release. This applies across all system components—frameworks, operating systems, middleware, and any production software the application depends on.

2. Enforce strong access control and password policies

PCI-DSS prohibits shared or generic group accounts. Every user must have a unique account. Passwords must meet the following minimum requirements:

• At least 7 characters in length
• Must contain both numeric and alphabetic characters
• Must be changed every 90 days
• Cannot reuse any of the previous 4 passwords

Account lockout policy:

• Accounts are locked after 6 consecutive failed login attempts
• The lockout must last a minimum of 30 minutes, or until an administrator manually unlocks the account

Session management:

• Sessions idle for more than 15 minutes must require re-authentication before access is restored

Default accounts:

• All vendor-supplied default accounts (such as administrator, sa, and root) must be disabled or removed before the application is deployed into a production environment.

3. Understand the scope of cardholder data

PCI-DSS applies wherever a Primary Account Number (PAN) is stored, processed, or transmitted. Understanding what data you actually need—and what you must never retain—is fundamental to scoping your compliance effort correctly.

The table below summarizes which cardholder data elements are permitted to be stored and what protections are required:

Data element	Storage permitted	Protection required
Primary Account Number (PAN)	Yes	Must be rendered unreadable
Cardholder Name	Yes	No additional requirement
Service Code	Yes	No additional requirement
Expiration Date	Yes	No additional requirement
Full magnetic stripe data	No	—
CAV2 / CVC2 / CVV2 / CID	No	—
PIN / PIN block	No	—

The general rule: sensitive authentication data must never be stored after authorization, even in encrypted form.

4. Remove custom accounts before production release

Any custom application accounts or user IDs created during development or testing must be removed before the application goes live. Leaving test credentials in a production environment is a common and serious security gap.

5. Conduct code reviews before deployment

Custom code must be reviewed prior to release to production to identify vulnerabilities—such as hardcoded credentials, improper input validation, or insecure data handling—before they can be exploited. Where possible, reviews should be performed by someone other than the original developer. A second pair of eyes changes what gets caught.

6. Separate development, test, and production environments

Development and test environments must be kept separate from production. Mixing these environments significantly increases risk—a misconfiguration or vulnerability in a development environment should never be able to affect production cardholder data.

7. Restrict access to the production environment

Access to the production environment must be limited to personnel with a documented, legitimate business need. Standing access should be the exception, not the rule. Access grants should be reviewed periodically and revoked promptly when no longer needed.

8. Never use live PANs for testing

Real Primary Account Numbers must never be used in development or test environments. Use synthetic or tokenized data instead. Exposing live PANs in a non-production context immediately expands your compliance scope in ways that are difficult to contain.

9. Remove all test data before go-live

Before an application is activated in production, all test data and test accounts must be removed. This includes sample records, placeholder credentials, and any data loaded during QA or UAT. Leaving test artifacts in production creates unnecessary risk and will surface as an audit finding.

---

Part 2 picks up with considerations 10 through 17—secure coding practices, encryption, audit logging, wireless security, and remote access—where the requirements get more technically specific and the implementation decisions start to compound.