A test suite that never fails isn't proof your code is solid. It's proof your tests aren't trying hard enough. Compliance controls work the same way.
If every control in your GRC tool shows green for all time and nothing has ever been challenged, that's not confidence. That's a false sense of it. And the difference between a real control and a record of intent is exactly where audits go wrong, and where founders get caught off guard.
The Jira Problem Nobody Talks About
Take a common setup in regulated software companies: Jira tickets used as evidence of a development control. The definition of done says the code was linted, scanned, reviewed, approved. The ticket is in the Done column. The auditor sees it, nods, moves on.
But here is what that ticket actually proves: that someone dragged it across the board.
In most Jira installations, there are few to no access controls on ticket state. A developer can move a card from To Do to Done in thirty seconds, with no linting run, no security scan, no peer review. The ticket says all the things happened. The ticket has no idea whether they did.
A less technical auditor will probably let it slide. A technical one will ask to see the pull request. And if you can drill down from the ticket to the PR and show the checks passed there, you got lucky. But now you have a different problem: your actual evidence lives in CI/CD, not in the process your work instructions describe. You're not working to your own SOPs.
The real control, if it exists, lives in branch protection. It lives in merge gates that block a PR from closing unless a lint report is attached, a JUnit file is present, and a reviewer has approved. The system physically will not let you proceed without it. That's enforcement. The Jira ticket is just a story someone told.
What a Real Control Actually Does
A real control makes circumvention either obvious or absurd. That's the test.
Physical access is a useful comparison. Many security standards require physical access control, and key card systems are the common implementation. The logs show who badged in and out. That looks like a control. But it doesn't tell you whether someone followed a colleague through the door. It doesn't confirm a visitor who said they were leaving actually left the building. There are gaps, and most key card logs won't surface them.
That doesn't mean key cards are useless. It means the control has limits, and you need to know what those limits are before you point an auditor at the log and call it evidence.
The question to ask about every control is: if someone wanted to circumvent this, how would they do it, and would there be any record?
A lazy employee who wants to skip a step. A disgruntled one who wants to hide something. Not because those situations are likely, they aren't in most companies, but because the thought experiment is clarifying. If the answer is "they'd do it easily and leave no trace," the control isn't a control yet. Keep iterating.
The target isn't perfection. It's making circumvention hard enough that it either produces obvious evidence or becomes genuinely absurd to attempt. At some point, every system does come down to whether someone wants to behave. But the goal is to shrink that surface area as far as possible before you get there.
Designing Controls Worth Keeping
When building out controls in a GRC platform, the question to sit with upfront is: how would this actually be recorded? Not "does this sound like a control" but "what artifact proves this happened, and can that artifact be faked?"
If the answer is a screenshot, a checkbox, or a ticket state, dig deeper. Ask who has the ability to produce that artifact without doing the underlying work. If the answer is "anyone," you have a gesture toward a control, not the control itself.
If the answer is a system-generated output that only exists when the action is taken, a passing CI run, a signed access log from a door controller, a timestamped approval from a required reviewer, you're getting somewhere.
The red-team framing is the most practical way to get there. Before finalizing any control, run through it once as the person who doesn't want to comply. See how far you get. If you get all the way to "done" without producing a single piece of unfakeable evidence, go back and redesign.
This is not a compliance-specific skill. It's the same instinct that makes a good QA engineer. The tests that find nothing aren't giving you confidence. They're just running.
Build controls that could actually catch something, and you'll have controls worth pointing an auditor at.