Two years ago, our external auditors came in for the annual review and asked me something nobody had ever asked me before. They didn’t want to see a contract. They wanted to see how my contract management system was set up.

Specifically, they wanted to know: Who can edit contract records after they’re finalized? What happens when a contract amount exceeds $50,000? Is there an approval workflow, and if so, who’s in it? Can someone skip a step? Where are the logs?

I’d spent years thinking of my CLM tool as a place to store and find contracts. It had never occurred to me that the way I configured it was, itself, a control. That the routing rules, the permission settings, the required fields: those weren’t just process decisions. They were audit evidence.

I was not ready for that conversation. I am now.

Why auditors started caring about your CLM settings

Here’s what changed: revenue recognition rules under ASC 606 made contract terms directly relevant to how companies book revenue. Performance obligations, variable consideration, payment contingencies: all of these live in your contracts, and all of them affect your financial statements. That means, under SOX Section 404, the controls around those contracts need to be documented, tested, and auditable.

CBIZ published a useful breakdown of what this looks like in practice. They note that 5 to 7% of SEC-registered companies report SOX material weaknesses, and 35 to 40% receive findings from PCAOB inspections. Contract-related controls, particularly around revenue recognition, are one of the most common areas of focus. Every stage of the approval process, CBIZ writes, should be documented with clear evidence: signatures, timestamps, or system audit trails.

That last phrase is the key. “System audit trails.” Not “Dave’s email confirming he approved it.” Not “I think Karen signed off, check Slack.” The system itself has to produce the evidence.

What “configuration as control” actually means

Let me make this concrete. Here are the things in my ContractSafe setup that I now treat as part of our control environment, not just workflow preferences:

Approval routing by contract value. Contracts under $25,000 require one approval. Contracts over $25,000 require legal review. Contracts over $100,000 require finance and executive sign-off. These aren’t suggestions. They’re enforced by the system. An auditor can look at the configuration and confirm that no contract above $100,000 could have been executed without finance approval.

Required fields before a contract can be marked “active.” Contract type. Counterparty. Effective date. Expiration date. Total value. Without these, the record stays in draft. This sounds minor, but it means every active contract in the system has the minimum metadata an auditor needs to assess it.

Permission levels. Not everyone can edit a finalized contract record. Not everyone can delete. Not everyone can change a contract’s status from “active” to “terminated.” The permissions are role-based, and the system logs who did what, when.

Date alert configuration. Renewal alerts fire at 90, 60, and 30 days. Expiration alerts fire at 120 and 60. These are documented, and I can show an auditor exactly when notifications were sent and to whom.

None of this required a consultant. None of it required a six-month implementation. But it required me to stop thinking of system configuration as IT housekeeping and start thinking of it as control design.

The conversation nobody prepares you for

PwC’s analysis of IPO filings from 2019 to 2024 found that 46% of companies going public disclosed at least one material weakness in internal controls. In the tech sector, that number was 54%. The most common root causes? Inadequate processes around revenue recognition, lack of documentation, and insufficient controls over financial reporting.

I’m not at an IPO company. Most of you reading this aren’t either. But the point isn’t the IPO. The point is that the bar for what counts as an adequate control environment keeps rising, and contracts sit right in the middle of it. If your company recognizes revenue based on contract terms (which is most companies), your auditor is going to want to see the controls around how those contracts are created, approved, modified, and stored.

And if your answer is “well, Dave handles it,” that’s not a control. That’s a person. People quit. People forget. People make mistakes. A control is a system that produces the same result regardless of who’s operating it.

What I document now (that I didn’t before)

After that first awkward audit conversation, I built what I call a CLM control matrix. It’s a simple document (one page, honestly) that maps each configuration setting to the control objective it supports. It looks roughly like this:

The approval workflow maps to the control objective that contracts above threshold values require appropriate authorization. The required fields map to the objective that all contracts contain minimum data for financial assessment. Permission restrictions map to prevention of unauthorized modifications. Alert configurations map to timely identification of renewal and expiration events.

I update it whenever I change a configuration setting. If I add a new approval tier or modify a permission level, the matrix gets updated and the change gets a note explaining why.

SOX requires companies to retain financial records and audit trails for at least seven years. That includes the system configurations that govern how contracts move through your process. If you change an approval threshold in March and an auditor asks about it in November, you need to be able to explain when it changed, why, and who authorized it.

I keep a simple changelog for this. Date, what changed, why, who approved. It takes five minutes per change. It has saved me hours during audit season.

This isn’t just for public companies

I’ve worked at small and mid-size companies my entire career. Most of them weren’t publicly traded. Most weren’t subject to SOX. So why should you care about any of this?

Two reasons. First, if you sell to companies that are SOX-regulated, they may need to audit your processes as part of their vendor risk management. I’ve been on the receiving end of vendor questionnaires that ask exactly the kinds of questions I’ve described here: who can modify contracts, what controls govern approvals, where are the logs. Having good answers makes you a more credible vendor.

Second, and more practically: the discipline of treating your system configuration as a control just makes your contract management better. When you force yourself to document why the approval threshold is $25,000 and not $50,000, you end up actually thinking about whether it’s the right number. When you restrict who can edit finalized contracts, you stop finding mystery changes three months later. When you log your configuration changes, you build institutional knowledge that survives turnover.

I started doing this because an auditor asked me a question I couldn’t answer. I kept doing it because it made my job easier in ways I didn’t expect.

Where to start

If you’re reading this and thinking “I have never once thought about my CLM configuration as an audit artifact,” you’re not behind. You’re normal. I was there two years ago.

Start with three things. First, document your current approval workflow. Who approves what, at what thresholds, and is it enforced by your system or just a policy nobody checks? Second, review your permission settings. Who can edit, delete, or change the status of contract records? If the answer is “everyone,” fix that today. Third, start a changelog. Next time you modify any system setting, write down what you changed and why.

That’s it. No framework. No maturity model. Just the minimum set of documentation that lets you answer the question “show me how your system is configured” without scrambling.

Because the auditor is going to ask. Maybe not this year. But eventually, they will. And the answer should be in your system, not in your head.