How to Run an Engineering Security Audit That Sticks

Pick one of three lenses and say so out loud: access and identity (who can reach what), the exposed surface (what an outsider can hit without credentials), or data handling (where customer data lives and who can export it). Trying to cover all three in one pass with a small team is how audits stall out after week two.

Match the lens to your actual risk. A company holding payment data should start with data handling. A company selling API access to other businesses should start with the exposed surface, since that is what a prospective enterprise customer will ask about first.

Decide how fast you will fix what you find before the list exists, or severity will get argued about instead of acted on. Federal directives require critical, internet-facing vulnerabilities to be patched within 15 days and high-severity ones within 30 days¹. You do not need to be a federal contractor to borrow that clock: adopting the same windows internally gives your team an argument for cutting scope on the next sprint instead of quietly letting a finding age.

Write the clock down somewhere your whole team can see, not just in the audit report. A remediation SLA that only lives in one document gets forgotten the first time a deadline collides with a launch.

Start with the attack surface an outsider can see without logging in: public repositories for committed secrets, exposed admin panels, subdomains nobody remembers standing up, and dependencies with known CVEs sitting untouched for months. This is where the cheapest, most embarrassing findings live, and fixing them takes hours, not weeks.

Then move to access control: who has production database credentials, whether former employees still have active tokens, and whether your CI system can push to production without a second person approving it. These two passes usually surface the findings that matter most, before you ever get to a full code review.

Work through the first pass in this order:

1. Search public repositories for committed secrets and look for exposed admin panels reachable without logging in.
2. Inventory subdomains nobody remembers standing up, and list dependencies with known CVEs left untouched for months.
3. List who holds production database credentials and whether former employees still have active tokens.
4. Confirm your CI system cannot push to production without a second person approving the change.

A finding that does not have a named owner and a due date inside your existing sprint tool will not get fixed. Score each finding on two axes, how bad it would be if exploited and how easy it would be to exploit, and work the top-right quadrant first.

For anything you cannot fix immediately, write down the compensating control and a review date instead of pretending the risk does not exist. If you pursue SOC 2 later, an auditor will likely ask for exactly this kind of documented exception, and having it already written saves the scramble.

For example, an audit turns up an exposed admin panel and a stale API token belonging to a former contractor. Score both on impact and ease of exploitation. The admin panel is easy to reach and damaging, so it goes to the top of the sprint with a named owner and a due date that matches your remediation clock. The token gets revoked the same day, since that takes minutes. A finding like an outdated internal library with no known exploit path might get a documented exception, a compensating control and a review date. A common mistake is assigning a finding to a team instead of a person, which tends to mean nobody owns it.

A one-time audit tells you where you stood on the day you ran it. Continuous evidence collection through a platform like Vanta or Drata keeps that picture current, pulling access logs, patch status, and vendor reviews automatically instead of someone screenshotting settings pages every quarter.

If your exposed surface is large enough that manual review missed things, an outside penetration test or a comparison of endpoint detection platforms is worth the cost before your next big enterprise deal, not after a prospect asks for a report you do not have.