A Graph Database, a Deadline, and Real Customer Data
A financial services firm runs an architecture review board that meets every four weeks. Its approved-technology list does not include graph databases. A fraud-detection team needs one to ship a regulatory-mandated capability in nine weeks. The standard path is a four-week board review followed by a six-week security assessment. Impatient, the team has already stood up a proof of concept in a pre-production environment using an extract of real customer data, including names and account numbers, reasoning that the data was 'just for testing'. Two years ago a similar exception for a document store was granted for 90 days and quietly became a permanent production dependency; the internal audit report called this out. The board chair wants to reject the request outright to reassert control, and the fraud team's lead says rejection means missing the regulatory date.
1. What is your decision on the graph database request, and what conditions attach?
Read the worked answer
Separate the technology question from the process violation, because they need different responses.
On the technology: approve a time-boxed trial. The need is real and the regulatory date is fixed. A blanket rejection trades a governance win for a compliance failure, which is not a good trade.
Conditions attached to the trial:
- 90 days maximum, named accountable owner, written exit criteria, and a review date already in the calendar.
- Compensating controls: isolated network segment, no production connectivity, access limited to a named list, backups excluded from general restore.
- Publication on the technology radar as 'trial', with explicit entry and exit criteria, so it is visible rather than tribal knowledge.
- An ADR recording the context, the decision, the alternatives rejected, and the consequences - including the debt if it is promoted.
On the process violation: do not fold it into the approval. Running real customer data outside approved handling is a separate matter with its own owner and its own escalation.
Explicitly rejected: granting the exception without an expiry. That is precisely how the document store became permanent.
2. How should the board change its process so that neither the bypass nor the permanent exception recurs?
Read the worked answer
The current process makes the bypass rational: four weeks plus six is longer than the entire delivery window, so a team that wants to comply has no compliant path.
Two tracks, same standards:
- Standard: unchanged, for production commitments and anything touching high-classification data.
- Expedited: five business days, smaller quorum, scoped security review limited to the actual deployment rather than a generic assessment. Available only for time-boxed trials with compensating controls.
Structural fixes for the permanent-exception problem:
- Every exception carries an expiry date, an owner, and automatic escalation to the full board on expiry. No silent renewal.
- Promotion to production always requires a fresh review, regardless of how well the trial went. Trial success is evidence, not authorisation.
- The radar has defined states - trial, assess, adopt, hold - with entry and exit criteria in writing.
- Decisions are published in a searchable log, so the next team can see what was decided and why.
Design principle. Make the fast path fast, not the punishment severe. Governance that only works by deterrence is governance that gets routed around.
3. What are the professional and ethical issues in the team's use of real customer data, and what is your first action?
Read the worked answer
The issues:
- Purpose limitation and minimisation. Testing is a different purpose from the one the data was collected for: fraud detection on live customers. 'Just for testing' is not a lawful basis, and the extraction itself is a new processing activity.
- Scope. Names and account numbers are not needed to validate graph traversal performance. The data is broader than the purpose requires.
- Accountability. The decision was made by a delivery team without the data protection officer, and the reasoning used to justify it would not survive being written down.
First action: stop further use, preserve logs, and notify the data protection officer and security function the same day. Whether it is a reportable personal data breach is their call under the applicable regime, not mine, but it must be assessed promptly because notification clocks may be running.
Then: replace the extract with synthetic or masked data, and record what happened and what changed. As architect I am obliged to escalate even though it delays a project I support - the schedule pressure is exactly why the escalation has to come from someone with no incentive to bury it.