Where we startedThe product was moving, but risk arrived late
The teams were building mortgage workflows around borrower documents, income and asset data. The environments operated to SOC 2 and GLBA expectations. Product pressure was real, and so were the consequences of handling sensitive data badly.
The recurring problem was timing. Teams would build a feature and meet basic questions near release: who can see this data, where does it live, how long do we keep it and what proves the change was reviewed? These were reasonable questions asked when the answers were expensive to change. The result was rework, waiting and avoidable tension between engineering and risk.
The operating changePut risk into product design
I worked with the teams to move those questions into design. A least-privilege access model takes a short discussion before development and a rewrite after it. A retention rule takes a line in a design or a migration later. The requirement stays the same. Only the cost changes.
Before development, a team needed four answers: what data does this touch, who should see it, how long should it exist and what evidence will the normal delivery process leave behind? Once these questions became routine, reviews became shorter and more useful.
What changed in the systemControls that worked at team scale
Data classification and movement rules became defaults. Product roles defined what processors, underwriters and support staff could see. Production access was limited, time-bound and had a documented exception path. Approvals and change records came from the tools the team already used, so evidence was produced by the work instead of reconstructed later.
We also made the release path predictable. The same checks happened in the same order and left the same record. This mattered more as the number of teams and releases grew. A control that depends on one experienced person remembering it does not scale.
I would not allow real borrower data to become the easy answer for lower-environment testing. It made development convenient by widening the risk. We chose to improve test data instead.
What improvedFewer surprises as delivery grew
Features stopped returning from release review for issues that were knowable at design time. Evidence requests became lookups instead of reconstruction work. Across SOC 2 and GLBA environments, teams shipped more predictably because the common decisions had already been turned into defaults.
Escalations did not disappear, and they should not. The remaining cases were genuinely unusual and deserved attention. The routine work no longer waited for a small group of experts.
What I learned
I would keep the four design-time questions. They are simple enough for every team to use and strong enough to expose an incomplete design early.
I would invest in realistic synthetic test data earlier. I would also move routine guidance out of a few people's heads sooner. Early in the work, I was one of those bottlenecks. The system became healthier when teams could answer common questions without waiting for me.
At scale, good controls are not extra steps. They are product and engineering defaults that let more teams make sound decisions on their own.