How Calethia compares
Most comparisons in this category are about getting to SOC 2, and on that everyone is roughly the same. The useful question is what happens in year three, when you need something the tool was never designed to express.
The real three-way choice
In practice most mature programs end up running two of these at once: a platform for what it covers, and a spreadsheet for everything else.
| Question | Calethia | Config-based platform | In-house |
|---|---|---|---|
| Time to first SOC 2 report | Weeks | Weeks | Months |
| Write a control the vendor never anticipated | Python function in your repo | Yes, but you maintain everything | |
| Connect a homegrown or internal system | Connector SDK | File a feature request, then wait | Yes, but you maintain everything |
| Add a framework nobody has productized | Map onto the common control spine | Yes, by hand | |
| Cost of adding your Nth framework | Mapping work, coverage starts high | Re-tag everything, if supported at all | Full re-derivation |
| Handling a long list of control exceptions | One-line import per exception, versioned in Git | Per-control exception UI, doesn't scale | Tracked by hand, easy to lose |
| Can you read the logic behind a passing control? | |||
| Evidence signed and independently verifiable | RSA-SHA256, RFC 3161 timestamps | Vendor-attested | |
| Keep policy documents where your team already reads them | Link a Google Doc or Confluence page; drift checked against live control results | Authored and kept in their app | Yes, but nothing reconciles them |
| Continuous monitoring without you maintaining it | |||
| Self-hosted option | Yes, on GCP |
Calethia is an early-stage platform and some of the above is still being built. Where that's true we have said so in the cell rather than in a footnote.
Detailed comparisons
Where each approach is strong, and where it runs out of room.
Config-based platforms
These are the category leaders, and they do well what they were built to do. If you need a SOC 2 report by a deadline and expect standard requirements, they will serve you well. Do not switch for its own sake.
Limits of this approach
- You get a fixed menu of checks, and anything not on the menu has nowhere to go
- You can't read the logic behind a control, so a check that never fails looks like a check that passes
- Anything they haven't built is a feature request, so your audit date depends on their roadmap
- Exceptions are managed one control at a time in their UI, so a long exception list becomes its own maintenance project
- Vanta ships a Claude Code plugin that opens remediation pull requests, so Calethia does not claim AI-assisted fixes as a differentiator
Calethia's approach
- Controls are Python you own, so there's no requirement you can't express
- Every check is readable, so you can see what it asserts
- A common control spine means your Nth framework is mapping work, not a rewrite
- If you're carrying an extensive list of custom exceptions, that's a one-line import, not a per-control UI workflow
- You can write what you need yourself, so you do not wait on our roadmap
Spreadsheets as overflow
No one chooses this as a product, yet most mature compliance programs run it. It holds the overflow: the controls the platform could not express, tracked by hand alongside it. A warehouse table is a spreadsheet with a better storage engine.
Limits of this approach
- Flexible, but nothing monitors it
- Each check depends on a person remembering to look
- No evidence trail an auditor can independently verify
- The maintenance burden lands on the person who built it, and that person eventually leaves
Calethia's approach
- The same flexibility, with checks that run on a schedule
- Evidence is signed and timestamped instead of stored as screenshots in a folder
- It lives in Git, so it survives the person who wrote it
- One system for standard controls and bespoke controls
NIST specification
OSCAL (Open Security Controls Assessment Language) is a government-backed data format for describing security controls, assessments, and compliance documentation. It is a specification, so it competes with no product. Buyers ask about it often.
Limits of this approach
- OSCAL defines how to describe controls in XML or JSON
- It requires tooling to be useful, since OSCAL itself doesn't run anything
- Designed for documentation and data exchange, not enforcement
- OSCAL export is planned and does not ship today
Calethia's approach
- Policies execute and produce evidence
- Python with IDE support instead of verbose XML or JSON
- Automated evidence collection and cryptographic signing
- A running platform, with no format to build tooling against
When you should not pick Calethia
We would rather say this here than three weeks into an evaluation.
You need the report and nothing else
If compliance is a gate to clear on the way to a deal and you have no intention of doing anything more with it, an incumbent will serve you well and the switching cost here is pure downside.
One tag, many frameworks
This is what keeps the Nth framework cheap. The policy is mapped to a control, and the control is already mapped to every framework that asks for it.
Example: MFA enforcement policy
Tagged once against the common control spine
from calethia import ResourceTypes, Result, Severity, policy
from calethia.ccf import CCF
from calethia.github import organization
@policy(
id="github.org.admin_mfa_required",
name="Organization Admins Have MFA Enabled",
severity=Severity.CRITICAL,
resource_types=[ResourceTypes.GitHub.ORGS_MEMBER],
frameworks=[CCF("access-mfa")],
)
def check_admin_mfa(ctx: organization.Context) -> Result:
"""Verify every org admin has 2FA enabled."""
for member in ctx.list_members():
if not member.is_admin:
continue
if member.two_factor_enabled:
ctx.pass_(member.to_resource(), "MFA enabled")
else:
ctx.fail(member.to_resource(), "No MFA")
return ctx.result()Test it with your hardest control
Take one requirement to whoever else you're evaluating, and then bring it to us. Whichever tool can express it wins. This takes less time than a feature matrix.