The Merger Data Map That Cannot Be Trusted
Following its acquisition of a 3,000-person logistics-software company, Halcyon Group must integrate data environments within 90 days. Halcyon’s data map lists 300 systems; automated discovery finds 1,100 SaaS applications, 60 TB of unstructured file shares, and 14 legacy databases. About 40% of the discovered data is unclassified. Personal data appears in unexpected places: a customer-support wiki, three test environments populated with production records, and a marketing team’s spreadsheet containing 180,000 contact records. Retention schedules exist but are not applied; 2,000 accounts belonging to former employees remain active. One acquired database contains health-insurance claims for 12,000 employees.
The board wants a complete inventory before any deletion, but the integration deadline is fixed and the acquired company’s CISO says a full mapping would take a year. The privacy office has four staff and no dedicated discovery engineer. A regulator has not opened an inquiry, but the company’s next audit is in six weeks.
1. Recommend a risk-based sequencing for the data inventory and classification work over the next 90 days. What should be mapped first, and what can wait?
Read the worked answer
A complete map is neither achievable nor the right first objective. The work should be sequenced by risk of harm, regulatory exposure, and irreversibility of the integration deadline.
Days 0–14: contain the obvious exposures. Identify and restrict the health-claims database, the three test environments, the marketing spreadsheet, and public-facing file shares. Disable the 2,000 stale accounts. These are not inventory tasks; they are containment tasks. Record what was found so the inventory reflects reality.
Days 15–45: map high-risk systems and data. Start with regulated/sensitive data: health claims, employee payroll and benefits data, customer PII, payment/financial data, and any data crossing the EU/UK boundary. For each, capture a minimum record: system name, business owner, data categories, approximate volume, location, lawful basis, retention rule, user populations, vendor/subprocessor, and access path. Use automated discovery and sampling for the 60 TB of shares; do not manually review every file.
Days 46–90: owner attestation for the long tail. Send scoped questionnaires to system owners for SaaS applications that may hold personal data. Prioritize applications with broad access or external sharing. Defer low-risk SaaS with no personal data and no integration dependency.
Classification should use a small tier set-restricted, confidential, internal, public-with examples and handling rules. The inventory should state confidence and last-verified date rather than pretending to be complete. The board’s “complete before deletion” demand should be reframed: deletion of low-risk duplicates can proceed under a documented hold process, while high-risk data is mapped first.
2. How should Halcyon handle the production data found in test environments and the 180,000-record marketing spreadsheet before the integration deadline?
Read the worked answer
Test environments. Production data in test environments is unauthorized processing unless there is a documented lawful basis and controls equivalent to production. Treat it as a potential incident. Immediately restrict access, preserve logs, and determine whether the data was exposed outside the test team. Purge the production records or replace them with synthetic or masked data. If masking is used, ensure it is irreversible and does not rely on the same production keys. Rotate credentials used by test systems. Then assess notification obligations: if the test environment was Internet-accessible or accessed by unauthorized persons, a GDPR/UK/California notification analysis is required. The remediation should include a policy and a CI/CD control that blocks production data from being copied into non-production environments.
Marketing spreadsheet. First establish provenance and lawful basis: were these contacts customers, purchased lists, scraped data, or event leads? Check the notice given at collection and whether marketing was within the stated purpose. If the source is unclear or the basis is invalid, do not integrate the records; suppress them and assess deletion. If the records are lawful, validate them against suppression lists, apply retention rules, restrict access, and move them into a governed system with an owner and audit trail. Do not let the integration deadline become a reason to ingest unverified data into the CRM. Document the decision: keep, suppress, or delete, with reasons.
3. Define five metrics the privacy office should report to the board to show progress without claiming a complete data map.
Read the worked answer
- Percentage of high-risk systems with a named business owner and a completed minimum inventory record. This shows accountability for the systems that matter most, not raw system count.
- Percentage of restricted-data stores that have been classified and have handling controls applied. This measures risk reduction rather than discovery volume.
- Number of test/dev environments containing production personal data, and number remediated. This directly tracks one of the most common and serious exposures.
- Number of stale or former-employee accounts disabled, and percentage of privileged accounts reviewed. Access is a leading indicator of breach risk during integration.
- Percentage of high-risk records covered by an applied retention and deletion rule. This shows whether retention schedules are operational, not merely documented.
Supporting context should include discovery coverage (which repositories were scanned), open exceptions with owners and dates, and incidents opened from discovery. The board should be told explicitly that these are risk-coverage metrics, not a representation that the data map is complete. A “percentage of all systems mapped” metric would reward box-ticking and obscure the high-risk gaps.