Scoping call
Compliance engineering

We build and run the security program your audit requires.

Identity, devices, cloud, logging, policies, and evidence, configured in your own accounts and tested on every system in scope. For SOC 2, CMMC, and the frameworks your customers ask for next, without hiring a security engineer, an IT administrator, and a compliance manager to get there.

CISSP · CISA · Independent of audit firms · Published prices

Engagement record Change log · p. 4
Disk encryption enforced Remediated 09-14
38 / 41 → 41 / 41 laptops
Change CHG-0418 Approved Dana Reyes Evidence MDM export Role CTO
MFA required, all users Remediated 09-09
62 / 62 accounts
Change CHG-0411 Approved Dana Reyes Evidence IdP policy Role CTO
Branch protection on main Remediated 09-03
27 / 27 repos
Change CHG-0402 Approved Marcus Chen Evidence GitHub audit Role VP Engineering
CloudTrail to central log Remediated 08-28
3 / 3 AWS accounts
Change CHG-0396 Approved Dana Reyes Evidence Config snapshot Role CTO
Controls verified 112 / 112
Illustrative excerpt. Names and figures are examples.
How we work

Evidence from every system in scope.

Auditors test a sample. We check every system, so the report your customer reads describes how your company actually runs.

41 / 41
laptops checked
open findings · 0
  1. 01An auditor’s sample · 5 of 41 · all pass
  2. 02Every system · checked 41 of 41
  3. 033 not enrolled in device management · finding
  4. 0441 / 41 · fixed before fieldwork
Every system in scope

Each control is tested on every account, laptop, and cloud resource it applies to.

Findings fixed before fieldwork

If a control works on nine servers and not the tenth, the tenth is a finding, and we fix it before the auditor arrives.

A record of every change

What changed, when, and who approved it.

Your accounts

We work in systems you own, and you keep an owner-level account we don’t control.

What we build

The engineering behind the audit.

SOC 2 and NIST 800-171 organize their requirements differently, but most of the technical controls in both land in the same six areas. Every Build engagement also covers the parts that aren’t technical: policies, risk assessment, security awareness training, vendor reviews, and the evidence the audit requires.

Control area 01 · Identity and access
What this area covers

How people and systems get access, what they can do with it, and how it’s removed. That covers employee and contractor accounts, privileged and service accounts, single sign-on across your SaaS tools, and access to production.

Scoped to your stack and the frameworks you’re pursuing.
In practice
Single sign-on with MFA enforced for every user
Administrative access limited to named roles
Access reviews on a set schedule
Access removed when someone leaves, within the time your policy sets
EvidenceIdentity provider policy and user export · signed access reviews · offboarding records matched to HR departures
Maps to · SOC 2
CC6.1, CC6.2, CC6.3
NIST 800-171 (CMMC L2)
3.1.1, 3.1.5, 3.5.3, 3.9.2
Control area 02 · Endpoints
What this area covers

Every device that touches company data: laptops, desktops, and mobile devices, whether company-owned or personal under a BYOD policy. Enrollment, encryption, patching, and malware protection across macOS, Windows, and Linux.

Scoped to your stack and the frameworks you’re pursuing.
In practice
Every company device enrolled in device management
Full-disk encryption, screen lock, and OS updates enforced
Endpoint protection installed and reporting
EvidenceDevice management compliance export · endpoint protection coverage report
Maps to · SOC 2
CC6.1, CC6.7, CC6.8
NIST 800-171 (CMMC L2)
3.1.10, 3.13.16, 3.14.1, 3.14.2
Control area 03 · Cloud and network
What this area covers

Your production environment in AWS, Azure, or Google Cloud, and the networks around it. Account structure, encryption and key management, network boundaries, configuration baselines, and backup and recovery, defined in code where your team works that way.

Scoped to your stack and the frameworks you’re pursuing.
In practice
Infrastructure defined in code, using the tooling your team already runs
Encryption at rest and in transit, with managed keys
Network boundaries and least-privilege service roles
Backups taken and restores tested
EvidenceConfiguration snapshots · infrastructure-as-code history · restore test record
Maps to · SOC 2
CC6.1, CC6.6, CC6.7, CC7.1 (A1.2–A1.3 when Availability is in scope)
NIST 800-171 (CMMC L2)
3.4.2, 3.8.9, 3.13.1, 3.13.8, 3.13.10, 3.13.11
Control area 04 · Vulnerability management
What this area covers

Finding and fixing weaknesses before someone else does. Scanning across hosts, containers, applications, and dependencies, remediation ranked by risk, patch tracking, and coordinating penetration tests and their findings.

Scoped to your stack and the frameworks you’re pursuing.
In practice
Scanning of hosts, container images, and dependencies
Findings ranked by risk and fixed within defined timelines
Exceptions documented and approved
EvidenceScan reports · remediation tickets with dates · exception register
Maps to · SOC 2
CC7.1
NIST 800-171 (CMMC L2)
3.11.2, 3.11.3, 3.14.1
Control area 05 · Logging, detection, and response
What this area covers

Knowing what happened and acting on it. Which logs to keep and for how long, alerting that reaches a person, and an incident response process your team has practiced, including the reporting your contracts require.

Scoped to your stack and the frameworks you’re pursuing.
In practice
Audit logs collected centrally and retained
Alerts routed to a named responder
Incident response plan, tested on a set schedule
EvidenceLog source inventory and retention settings · alert routing configuration · incident and tabletop records
Maps to · SOC 2
CC7.2, CC7.3, CC7.4, CC7.5
NIST 800-171 (CMMC L2)
3.3.1, 3.3.5, 3.6.1, 3.6.2, 3.6.3, 3.14.6
Control area 06 · Change management
What this area covers

How code and configuration reach production. Code review, protected branches, security checks in the pipeline, separation of duties, and a record that ties each change to its approval, for application code and infrastructure alike.

Scoped to your stack and the frameworks you’re pursuing.
In practice
Protected default branch with required review
Security checks in the build pipeline
Every production change traced to an approved request
EvidenceRepository settings export · pipeline configuration · change records matched to deployments
Maps to · SOC 2
CC8.1
NIST 800-171 (CMMC L2)
3.4.3, 3.4.5

Requirement IDs from the AICPA Trust Services Criteria (2017, revised 2022) and NIST SP 800-171 Rev 2.

The alternative

The team you’d otherwise hire.

Getting through an audit takes security engineering, IT administration, and compliance management. Most companies your size have none of those roles yet.

Security engineer

Configures cloud, identity, and logging controls, and fixes what the audit finds.

$129,180
Median · BLS, May 2025 (information security analysts)
IT administrator

Enrolls and manages devices, accounts, and access.

$99,130
Median · BLS, May 2025
Compliance manager

Writes policy, runs risk and vendor reviews, and manages the audit.

$144,000
Median total · Glassdoor, 2026 (GRC manager)

About $372,000 in salary before benefits, which make up about 30% of total compensation (BLS, June 2026). Security roles often take 3–6 months to fill (ISACA, 2025).

Frameworks

Whatever your customers ask for, the work is the same.

Every framework comes down to the same work: read the requirement, build it into your systems, document it, and prove it. What changes is scope, the assessor, and a handful of technical rules. Those differences are what we plan around.

Primary
Also delivered

Works with Vanta, Drata, Secureframe, or no platform at all. The platform tracks the controls. We build and run them.

Who does the work
Austin Van Camp, Founder and Principal of Aletheon

Someone who speaks both languages.

Compliance requirements are written for auditors. Your systems are run by engineers. Much of the friction in an audit happens in the translation between the two, and in the handoff between the consultant who interprets a requirement and the engineer who has to build it.

Each engagement is led by Austin Van Camp (CISA, CISSP), who has more than ten years of experience building and running the systems these requirements describe. He interprets the requirements, configures the controls, and walks your auditor through them. Because one person carries the work from start to finish, we take on a limited number of engagements at a time.

Based inDenver, Colorado
ClientsAcross the United States
About Aletheon →
Common questions

Before you book a call.

Do we need a compliance platform like Vanta or Drata?

No. If you have one, we work inside it and do the engineering it flags. If you don’t, we organize the evidence for your auditor directly.

Who pays the auditor?

You do, directly. The audit or assessment firm’s fee is separate from ours. We can help you choose a firm, and we take no referral fees from any of them. We prepare you for the audit; we never perform it.

Should we get a SOC 2 Type 1 or Type 2 report?

A Type 1 checks that controls are designed and in place on a single date. A Type 2 tests that they operated over a period, usually three to twelve months. Many companies get a Type 1 to unblock a deal, then start the Type 2 period right away.

How long does a first SOC 2 take?

A first Type 1 typically takes three to six months from the start of work. A Type 2 adds the observation period. After the Assessment, we give you a specific date.

Which frameworks do you work with?

SOC 2 and CMMC are our primary practice. We also deliver ISO 27001, HIPAA, HITRUST, and CSA STAR, and advise on FedRAMP readiness. The engineering is largely shared, so a second framework usually builds on controls you already run. See SOC 2 and CMMC.

Start here

Book a 30-minute scoping call.

Tell us why you need an audit and what you run. We’ll tell you what it will cover, how long it should take, and roughly what it will cost.