PCI Requirement 6.3.1 – Remove Development and Test Accounts, User IDs, and Passwords Before Release

PCI Requirement 6.3.1 – Remove Development and Test Accounts, User IDs, and Passwords Before Release

Why Remove Test Data Before Production?

PCI Requirement 6 says that software applications should be developed in a secure way, which requires that your organization go through many phases to ensure information security is incorporated throughout the application. PCI Requirement 6.3.1 picks up during the development phase and testing phases. PCI Requirement 6.3.1 states, “Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.”

During the development and testing phases, it’s likely your organization will use test data. This might be test accounts, IDs, passwords, or test data from a database of mock data. When your applications go from development and testing into production, the PCI DSS requires that all of this development data and testing information be removed from the application before it gets put into production. If this data is not removed before the application becomes active, the data could compromise the application.

During a PCI assessment, an auditor will examine the software development policies and procedures and interview the person responsible for removing test data from the application before production.

Video Transcript

During your development phase, it’s likely your organization is going to be using test data. This might be test accounts or you might have actual test data from a database full of mock data. When those applications get pushed from development into production, we want to make sure that all of that development environment and development information is removed from the production application before it gets put into production.

Often when we run a pen test, the first account that I’ll use to try to get into an account is “Test Test” or “Test 123” or various test accounts like that. One of the things that an assessor will do is find out how you’re authenticating, if you’re authenticating. We’re going to find out how you’re storing or interacting with that database. However you do that, whatever the data is, however it might reside, wherever it might reside, we want to make sure that data is not pushed into production. Your assessor should be looking at that process, interviewing your developers, and actually looking at that data set as part of the onsite portion of the assessment.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *