I talk pretty frequently to teams who have run into issues setting up current compliance platforms. Almost uniformly, they struggle with rigid interpretations of framework controls that require them to contort their business to meet predefined requirements.

They typically don’t have experience with compliance, and they’ve already paid for the platform based on a demo, because no one else in the industry offers free trials. So now they’re in the sunk cost landscape: choosing between implementing controls in a way that doesn’t really fit their business OR writing custom controls in a tool that doesn’t really support customization. 

Further, platforms that push control language on their clients actually increase the cost of obtaining a SOC 2 report because they portray their version of control language as "the requirement", and clients end up implementing systems and processes they don't actually need (or missing out on implementation of key systems and processes that they DO need). 

We know why they do this: Many compliance systems attempt to accomplish their "streamlined automation" by specifying the controls rather than having the controls tailored to their clients’ businesses. As we shared in a post about “Why DevOps Engineers Hate Compliance,” that approach enables them to automate “the least meaningful components of compliance while reinforcing the structural flaws that created the problems in the first place.”

This pattern shows up across nearly every part of a compliance program, but Background Checks are a great example:

If you use a rigid platform: you get a requirement for “background checks”. You end up paying for a background check service, integrating it, and manually uploading sampled evidence … even if you haven’t hired anyone during the observation period.

From the auditor side, there is no SOC 2 control that explicitly states background checks are a requirement. What auditors are really looking for is documentation of your hiring policy and evidence that consideration of the background of employees and contractors is performed based on your company’s established expectations and standards (this is CC1.4 POF5).

Startups, especially those not planning to hire within the observation period; may not need to implement this control in this way. You certainly shouldn’t be paying for a background check service if you aren’t hiring. An appropriate consideration of background might be something as simple as “we personally evaluate all candidates based on key criteria including our experience of their work ethic from previous collaboration”. If you can provide evidence of this process, then you don’t need to go implement tools or set up integrations that aren’t currently a good fit for your team.

Change Management is another commonly over-designed control from rigid platforms. Different control, same outcome -a flexible requirement gets turned into a rigid implementation:

If you interpret CC8.1 to mean that “every test needs a ticket and approval” because of a tool-provided test and integration, you end up implementing a system where: 

• Every code change requires a JIRA ticket
• Every JIRA ticket requires approval before merging PRs
• Every PR must link back to that ticket

Not because your business needs it, but because the tool does.

What auditors actually require is evidence that changes are authorized, documented, tested, and traceable. Startups can solve this with much lighter and completely valid alternatives like: 

• Git-based workflows that aren’t manually tracked in some other system (you can conduct PR reviews, approvals, and track commit history directly in GitHub).
• CI/CD logs showing testing and deployment

The same thing happens in vulnerability management, where tools enforce unrealistic remediation SLAs that don’t reflect real engineering backlogs.

The Consistent Pattern

Controls meant to provide reasonable assurance get encoded as one option that works for their software and auditor network.

The platform provides a templated, required control. Users assume this is the framework’s requirement, and suddenly, flexibility disappears, replaced by process, tooling, and cost that were never actually necessary.

Many teams aren’t deeply experienced with compliance frameworks and don’t have a guide leading them through the process, so they go spend money, accept policies they didn’t write, and implement the very compliance theater they hate. 

This isn’t just philosophical. It shows up directly in cost, time, and unnecessary tooling.

There is a Better Way

At Openlane, flexibility isn’t just superficially about “keeping the controls you like”. The framework defines the requirement, and your controls should reflect how your business actually operates. Customization is what keeps you from adding tools, processes, and costs you don’t need.

Instead of prescribing controls, we help you:

• Understand the intent of the control

• Map directly to the framework

• Implement in the tools and workflows you already use

• Provide the right evidence for your audit

Let’s take that background check example: 

With Openlane, you define a control that states, “Hiring Managers personally evaluate all candidates based on key criteria including experience of candidate from previous collaboration, considering background, skill set, and technical competency.

You include a paragraph in your Human Resources Policy that explains this policy, and you map both your control and the policy back to CC1.4 POF5 and POF6. 

Whether you use an HR tool or Google Drive, you implement a location to track employee files: interview notes, background verification, reference checks, NDAs, etc. 

At the end of your observation period, your auditor checks the integration with your identity provider and confirms you have 1 new hire from the period. They request evidence of your evaluation process, and you provide it. Done!

This same pattern applies across controls, whether you’re working on change management, vulnerability management, access reviews, or even password rotation. Your implementation reflects your business, not the tool’s most-efficient approach.

We partner with high-quality auditors who are not looking for a sheet of green checkmarks they can sign. They evaluate controls based on control effectiveness and appropriateness, not conformity, and they seek “reasonable assurance”, not perfection. 

SOC 2 was never meant to standardize how companies operate. It was meant to ensure they understand and can demonstrate why their controls work; while demonstrating a level of maturity and risk management that aligns with their service commitments, system requirements, and the SOC 2 Criteria. 

The tools we build at Openlane support that process, rather than trying to replace it.