The Ethical Shortcut on Test Data
You are the business analyst on a payroll migration for a 3,000-employee company. Testing needs realistic data. A developer proposes copying the production payroll database into the test environment to "save three weeks." The test environment is on a shared internal server accessible to the 20-person project team and two offshore contractors. The production database contains bank account numbers, tax identifiers, and salary data. The project manager says "everyone on the team is cleared anyway" and asks you to note the approach as acceptable in the test plan. Go-live is in six weeks.
1. What is your response, and what alternatives would you propose?
Read the worked answer
I would not sign off on copying production payroll data into a shared test environment. The reasons are concrete, not theoretical:
- Scope of access. Twenty team members plus offshore contractors is a wider audience than the production system's controls assume. "Cleared" is not the same as "needs salary and bank data to test."
- Legal and contractual exposure. Payroll data includes tax identifiers and bank details; copying it may breach data-protection obligations and contractor agreements, and it creates a reportable incident if misused.
- Audit trail. Test environments typically lack production-grade logging, so misuse would be hard to detect.
Alternatives:
- Masked or synthetic data. Generate test records with realistic structure but altered identifiers and salaries. This is the standard approach and can usually be scripted in days, not weeks.
- Subset with masking. Copy a small sample and irreversibly mask sensitive fields.
- Targeted production read-only access for specific verification cases, logged and time-boxed, if masking is insufficient.
Propose option 1 with a short proof-of-concept to show the three-week saving is overstated.
2. The project manager pushes back and asks you to record the approach as acceptable. How do you handle the disagreement professionally?
Read the worked answer
Disagree openly, document accurately, and do not sign something I believe is wrong.
Steps:
- Restate the concern in writing with the specific risks and the alternatives, and ask the PM to confirm the decision in writing if they still want to proceed. A written decision is different from my endorsement.
- Offer a compromise that protects the schedule: a two-day masking proof-of-concept, and if it works, the test data is ready before the original copy would have been.
- Escalate to the data protection officer or project board if the PM insists. This is a legitimate escalation, not disloyalty; the organization carries the legal risk.
- In the test plan, record the decision, the owner, the residual risk, and my recommendation. I will document the decision; I will not label it acceptable.
Tone: stay factual and solution-oriented. The goal is a safe test approach on time, not to win the argument. If overruled and the copy proceeds, I would ensure access is restricted and logged, and note the residual risk for the board.