How Organizations Can Simplify Compliance Audits by Including Controls in Daily Operations
Published
Key Takeaways
- Carhart says closer coordination with security, engineering, legal, and sales can prevent conflicting priorities from slowing the program.
- A successful audit reflects a particular period and cannot prevent permissions or controls from changing afterward.
- Access reviews and employee offboarding can reveal the widest gaps between written policies and practices.
- SOC 2 and ISO 27001 cannot be treated as identical checklists because they assess compliance through different approaches.
- Comp AI observes automation can handle routine evidence collection so people can focus on controls that reduce risk.
Lewis Carhart, CEO and Co-Founder of Comp AI, explains why a company can pass an audit and still remain exposed to security risks. Carhart’s background includes leading IT and security at FutureOn, heading growth at Leap AI, and co-founding LinkDR and Headshot Generator AI.
He says organizations struggle when they treat compliance as a project that ends after certification. The work then becomes a yearly rush to prepare evidence instead of being part of everyday tasks such as software deployment, access removal, and vendor reviews.
Compliance teams also face pressure from several directions. Sales wants reports quickly to close deals, and legal teams want precise language. Carhart notes that an audit only shows whether selected controls worked during a particular period. Afterward, permissions may expand.
Carhart believes annual audits should not be the main measure of trust. Read on for complete insights into the gaps between passing an audit and maintaining security throughout the year.
Vishwa: What do you notice in the organizations that struggle the most with compliance? Security, engineering, compliance, legal, and sales teams all have different priorities. Where do you see friction during a compliance program?
Lewis: They treat compliance like a project. A start date, an end date, and an owner who's relieved when it's over. You'll see it show up as a 200-hour audit-prep slog once a year, then silence until the next cycle.
The companies that don't struggle build compliance into the actual workflow:
- Deployment pipelines
- HR onboarding
- Vendor procurement
It's not a separate task. It's just how the company operates. Sales wants the SOC 2 report today because it's blocking a deal. Engineering wants to ship, and every control feels like a tax on velocity. Legal wants the language airtight, which slows everything down. Compliance sits in the middle, translating between all of them, and usually gets blamed by everyone.
The friction isn't really about compliance. It's that compliance is the one function that has to talk to every other function, and most orgs never build that muscle until it hurts.
Vishwa: At what stage of a compliance journey do leadership teams usually realize they misunderstood what the work would actually involve? What lessons could be learned when organizations experience an incident after passing an audit?
Lewis: Right after they pass the first audit. There's this assumption that the audit is the finish line. Then a new hire doesn't get offboarded on time. Or a vendor renews without a security review.
That's when leadership realizes the report they just paid for is a snapshot of one moment. Not a guarantee about next Tuesday. Compliance isn't a deliverable. It's an operating condition.
The lesson after an incident: A clean audit report describes the past. Not the future.
The most common pattern:
- An incident traced back to something that was compliant on the day of the audit and drifted afterward.
- A permission that got broader.
- A vendor that changed its own posture.
- A control that was never actually automated and quietly stopped happening once the person who owned it moved teams.
The part people don't want to hear: you can fail nearly every real security check and still walk away with a clean cert.
The cert exists to give your buyer peace of mind; it's a box they tick when onboarding a vendor. It doesn't mean your systems are locked down. It doesn't mean you won't get breached.
If you treat the audit as your actual security strategy, you're already in trouble. The lesson isn't "the audit failed." It's that you need monitoring that runs at the speed of your actual risk, not the speed of your audit cycle.
Vishwa: You've said that compliance should move beyond point-in-time audits. What parts of the audit process feel disconnected from how security teams actually operate throughout the year?
Lewis: The sampling model. Auditors pull evidence from a handful of dates across the period and extrapolate. Security teams don't operate in samples. Access changes, new vendors, config drift, that's every single day.
So you get a report that says "this control operated effectively" based on maybe 3-5 data points, when the actual risk surface changed dozens of times in between.
Sampling is how you make an audit tractable. Fine. But the format was built for a slower-moving world than the one security teams live in now.
Vishwa: Many organizations become audit-ready but struggle operationally. In your experience, where does documentation stop reflecting reality? What controls do organizations underestimate until they begin implementing them?
Lewis: Access reviews and offboarding. Almost every time. The policy says access gets reviewed quarterly and revoked within 24 hours of termination.
The reality is someone in ops manually cross-referencing a spreadsheet against an HR system that isn't actually connected to anything. It looks clean on paper because the paper describes the intended process, not the actual one.
That gap is almost always a systems-integration problem wearing a documentation costume.
The organizations underestimate vendor risk management. Everyone treats it like a form you send once, at onboarding. In practice, it's ongoing. Vendors get breached. Sub-processors change. A tool you approved for one narrow use case quietly becomes load-bearing infrastructure.
Most companies build a great process for the front door and ignore everything that's already inside the building.
Vishwa: Compliance frameworks often use similar language around policies, evidence, and controls. What differences matter most between frameworks such as SOC 2 and ISO 27001 once implementation begins?
Lewis: SOC 2 is an attestation over a period of time. An auditor's opinion on whether your controls operated effectively across, say, six or twelve months.
ISO 27001 is a certification of a management system. It's less about proving specific controls worked, more about proving you have a functioning risk-assessment process that decides which controls matter and why.
ISO pushes you toward a living Statement of Applicability and ongoing risk treatment.
SOC 2 pushes you toward continuous evidence tied to specific trust service criteria.
Treat them as interchangeable checklists and you'll do twice the work. Understand the philosophy underneath each one, and 70-80% of the effort overlaps.
Vishwa: What do companies misunderstand about continuous evidence collection? Where does automation genuinely reduce effort, and where can it create a false sense of assurance?
Lewis: Automation is great at proving a control exists. MFA is enabled. A ticket got closed. An integration says "connected."
It's much weaker at proving a control is actually effective. A green checkmark that says "encryption is enabled" doesn't tell you whether the key management behind it is any good.
Here's the part people miss: you can fail almost every real security check and still pass an audit, if the paperwork lines up.
The false assurance creeps in when teams treat "the dashboard is all green" as the same thing as "we are secure."
Automation should kill the busywork, screenshots, tickets, config exports, so humans have time to ask the harder question: does this actually reduce risk, or does it just satisfy a checkbox?
Vishwa: Were there moments that changed your view of what effective compliance should look like? If you could remove one practice from the compliance industry, what would it be, and what would you replace it with?
Lewis: Watching a 3-person team support hundreds of customers. Most people look at that ratio and assume you're understaffed. But you can build it deliberately so headcount and customer count don't have to scale together.
Most SaaS companies treat support as a headcount problem. Treat it as an engineering problem instead.
Every time a customer asks something the system can't answer, you get on it immediately, add it to the knowledge base, and make sure it never comes back to a human again. Every unanswered question is a gap in the system, not a staffing problem.
That reframe, treating operational load as a solvable engineering problem instead of a hiring problem, changed how I think about compliance too.
The goal isn't more people checking more boxes. It's building something that verifies itself, so people only touch what actually needs a human.
I would remove the annual point-in-time audit as the primary measure of trust. And replace it with continuous, verifiable monitoring that produces an audit as a byproduct, not a goal.
The audit shouldn't be the thing you build toward once a year. It should be a report generated from a system that's already proving itself true every day.
Trust shouldn't have an expiration date measured in months.
Related
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular