The Audit You Wish You Ran Before the Compliance Review

Jeff Moser, BitSalt

The compliance review email usually lands on a Tuesday, and I’ve seen a few of them. Forty-three line items, six weeks until the review, and somewhere around line twelve — “Describe your process for rotating secrets and credentials” — the mood on the call shifts.

The team knows the answer. That’s the problem.

Why teams find out during the review

Most small engineering teams aren’t negligent about security. They’re prioritized against it. There’s a difference.

I’ve seen this often enough to recognize the pattern: rotation got set up during initial provisioning, back when there was an afternoon to do things right. Since then the team added more services, more environments, a contractor who needed temporary credentials, features shipping every two weeks. The secrets in the AWS account reflect all of that history, including the parts nobody remembers anymore.

A compliance audit doesn’t care about sprint velocity. It wants to know what’s actually configured, right now, in production.

What the frameworks actually ask

The specific questions vary by framework, but whether it’s SOC 2, ISO 27001, or CIS Controls, the underlying concerns are consistent:

  • Are credentials rotated on a defined schedule, and can you prove it?
  • Are there secrets that haven’t been accessed in months but still have active policies?
  • Who or what can access your secrets, and is that access still appropriate?
  • If a secret was compromised, how quickly would you know?

These aren’t trick questions. They’re reasonable things to want to know about a production system. Without running a deliberate audit ahead of time, you’re answering them from memory. Memory is optimistic.

Four things I’ve seen on every audit

Rotation configured but silently failing. AWS will show a secret as “rotation enabled” even if the last several rotation attempts errored out. The checkbox is green. The credential hasn’t actually rotated in four months. This is probably the most common finding, and the most embarrassing one to explain.

Stale secrets that nobody deleted. The contractor’s credentials. The integration with the vendor they stopped using. The test secret from the proof-of-concept that became production. Still there, still valid, still attached to policies that grant real access. Out of sight, not out of scope.

Overly broad resource policies. Early in a project, "Resource": "*" is expedient. It tends to stay that way. An auditor asking which principals can access this secret and why deserves a better answer than “anyone with the right role in the account.”

No access logging reviewed. CloudTrail captures secrets access. Most teams have it enabled. Almost none have looked at the logs for secrets specifically unless something broke. If nobody can describe who accessed a given secret in the last ninety days, that’s a posture gap, and now it’s also a line item.

Running it before they ask

Not the week before. Far enough ahead that findings become action items rather than explanations.

Concretely: pull every secret in every account and environment. Check rotation status and last rotated date, not just whether rotation is enabled. Look at resource policies for anything broader than it needs to be. Flag anything that hasn’t been accessed in ninety days and verify it’s still needed. Review who can call GetSecretValue and whether that list still makes sense.

Six weeks sounds like enough time. It isn’t, once you factor in the back-and-forth, the remediation work, and the other forty-two line items on that questionnaire. Teams that run a proactive audit, even informally, even once a quarter, already know what their posture looks like before anyone asks.

Document what you find and what you did about it. Auditors aren’t expecting perfection. They’re evaluating whether you have a process and whether you follow it. That’s a different question, and a more answerable one.

Redactus is being built to automate most of what’s described here: pulling secrets configuration, checking rotation health, flagging stale and overpermissioned entries, and generating an exportable report. It’s in development. Get notified when it launches.