Enterprise clients in Germany start asking about compliance early. Not as a formality. As a real requirement that gates procurement. The questions are specific: how do you handle secrets, what does your incident response look like, who has access to production, how do you manage dependencies with known vulnerabilities.
These are good questions. They're also questions that most engineering teams can't answer cleanly the first time they're asked.
What compliance actually requires from engineering
Not certification. Not an audit. The baseline requirement is that you can demonstrate your practices are defensible. That means the practices exist, they're documented, and people follow them consistently.
Access control is the first thing clients ask about. Who can access production? How is that access managed? What happens when someone leaves the team? In most early-stage engineering teams, the honest answer is: it's mostly fine, handled informally, and not written down. That answer doesn't work with enterprise clients in regulated industries.
Dependency management is the second. Clients running infrastructure in sensitive contexts need to know you're tracking CVEs in your dependencies and have a process for addressing them. Not that you patch everything immediately, which isn't realistic. That you know what you're running and have a documented decision process for what to prioritize.
Secrets management is the third. Credentials, API keys, certificates: how are they stored, who can access them, how are they rotated? "In a .env file that we don't commit to git" is a start. It's not a compliance answer.
What the gap usually looks like
The practices exist informally. The team uses a password manager. Someone keeps a list of who has production access. Dependencies get updated when something breaks or when a critical CVE makes the news. None of it is written down because it didn't need to be.
When a client asks for documentation, the engineering team has to reconstruct from practice to policy. This takes longer than writing the policy would have taken in the first place. It also surfaces gaps: the informal practice has exceptions that nobody documented because nobody needed to explain them before.
What we actually did
Wrote an access control policy. Who gets production access, under what conditions, with what approval, reviewed quarterly. Took half a day. Should have existed for two years.
Set up automated dependency scanning in CI. Dependabot for the main services, reviewed weekly. The number of flagged vulnerabilities was higher than expected when we turned it on. Most were low severity. A few needed attention. The automated scanner is now a normal part of the workflow.
Moved credentials to Secret Manager and documented the rotation schedule. The rotation schedule is the part that requires discipline. Tooling makes rotation easy. Doing it consistently requires someone owning it.
Wrote an incident response runbook. Not a long document. A clear description of what P1 and P2 mean for us, who gets notified at each level, and the expected response timeline. The runbook doesn't handle every scenario. It handles the common ones and gives the team a starting point for the others.
The honest observation
None of this is technically interesting. It's the operational hygiene that should exist in any production system that people depend on. Compliance requirements are often what finally creates the pressure to formalize practices that should have been formalized earlier.
If you're waiting for a client compliance questionnaire to force this work, you're doing it at the worst possible time: under deadline pressure, while also trying to close a deal. Do it before you need it.
With gusto, Fatih.