My approach to data governance, security, legal, and architectural best practices

I tend to think about our work the way I think about houses: new construction, renovations, the occasional gut job. And anyone who's built or remodeled a place knows you don't get to pour the foundation just because you're excited about the kitchen. First you go through permitting.

That's how I treat the mandatory bureaucratic procedures here. I call it "house permitting": the data governance, security, architecture, legal, and support checks that every project has to clear before it's allowed to exist.

Data governance

Think of this as the part where you prove you're allowed to do what you're about to do.

We use personally identifiable information only when we actually need it, and when we do, it gets the security controls that match. European requirements have to be met, full stop; they're not optional and they're not negotiable. And none of this goes forward on one person's say-so. The work gets reviewed by the company and by the right legal and employee-relations specialists before it moves.

Security

This is where we decide how strong the locks and walls need to be, and the answer depends on what's inside the house.

Given the nature of the information, we put the matching controls in place. Sometimes that's login and password plus MFA; sometimes it's IP whitelisting and certificates. Engineers make sure the standard requirements are all met: data encrypted at rest, HTTPS everywhere, OWASP standards followed, sound architectural patterns for moving data securely between platforms, and proper key storage. We bake security tooling straight into the CI/CD pipeline so every PR gets checked for compliance as it goes by, with no relying on someone to remember. And on top of all that, we run regular pen tests, because the only way to know your locks hold is to have someone try the doors.

Architecture

Before you build a new wing, you walk the house you already have.

So before we build anything new, we make sure we're using our own services, and our neighboring teams' services, to their full extent. No reinventing rooms that already exist down the hall. We also plan not just for the feature in front of us, but for the future, so what we put up can actually grow. And we bring in experts to guide the team toward genuine industry best practices, rather than learning every lesson the expensive way.

Legal

This one's short and simple: whenever there's doubt about new functionality, we consult legal. Better to ask the inspector before you knock down the wall than after.

Production support plan

Finally, you don't hand someone the keys without telling them where the breaker box is.

For every new application rollout, we create a plan, including scripts for the most common troubleshooting scenarios and a clear path for escalation. We make sure support is actually notified about major feature releases, so they're not caught off guard. And we go back through the logged tickets to see whether the most common issues can be designed away entirely.

That's the permitting process. It's slow, it's careful, and it's the reason what we build keeps standing.