Skip to content

SOC 2 technical readiness

Your SOC 2 blockers are engineering problems.

I clear the technical findings in your actual AWS, GitHub, and identity provider, so your controls hold up before the observation window opens, instead of finding out what's broken in month three of it.

This is the engineering half of the work: controls, tooling, and evidence. The compliance program stays yours. See exactly where that line sits below.

Request the diagnosticCommon findings

Common technical findings, caught before the audit.

This is what the diagnostic goes looking for first. None of it is exotic. These are the issues that frequently surface during readiness reviews and first audits, and most are straightforward to fix once someone with console access is actually looking.

MFA isn't actually org-wide

Enforced in the IdP, quietly bypassed by local logins, service accounts, and the two admins someone grandfathered in.

The AWS root account has active access keys

Hard to justify in any review, and they tend to turn up in a CI config that nobody remembers adding.

Secrets are sitting in git history

Rotating the key doesn't remove it from history. The commit is still there, and automated secret scanning will keep finding it.

0.0.0.0/0 on SSH and database ports

Almost always a security group opened for one debugging session two years ago and never closed.

No branch protection on the default branch

Change management is a control. If anyone can push straight to production, there's no evidence to hand over.

CloudTrail isn't producing a usable audit trail

Single-region, log file validation off, or writing to a bucket the same admins can delete from.

Backups have never been restored

Having backups is not the control. Proving you can restore from them, on a date, is the control.

Terminated users still have live access

The IdP was deprovisioned on their last day. The GitHub org, the IAM user, and the Postgres role were not.

Two ways in.

The diagnostic stands on its own. Plenty of teams take the report and fix things themselves. The sprint is there if you'd rather it were already done.

Diagnostic

from $3,000

Credited toward the sprint if you proceed.

A paid gap analysis run against your real environment (AWS, GitHub, and your identity provider), not a questionnaire about it. You get the findings whether or not you hire me for the remediation.

What's included

  • Read-only review of your AWS accounts, source control, and IdP configuration
  • Findings mapped to the relevant technical controls and the evidence each one is expected to produce
  • Each item ranked by severity against the engineering effort to close it
  • An executive summary for leadership: current technical risk, priority findings, and the remediation plan
  • A walkthrough call to challenge the findings and agree on priorities

What it isn't. This is not a penetration test, a security audit, or an audit opinion. It's an engineering review of the controls a SOC 2 will expect you to evidence.

Remediation sprint

Fixed-fee, scoped from your diagnostic

A defined 2–4 week block with an agreed list and an end date.

I fix the findings in your environment, in your repos, with your review process. Quoted after the diagnostic, because quoting it before means either padding the number or renegotiating halfway through.

What's included

  • The diagnostic's findings closed, in priority order, as reviewable pull requests
  • Identity, access, and offboarding tightened across AWS, GitHub, and the IdP
  • Logging, alerting, and audit trails configured to actually retain evidence
  • Backup and restore tested, with the restore documented and dated
  • Infrastructure and CI changes committed as code, so the controls hold after I leave
  • A handover doc your team and your auditor can follow

Where my half stops.

A SOC 2 is more than its technical controls, and I'd rather be blunt about the parts I don't touch than let you discover them in week three.

  • Policy authoring and the policy library.
  • HR controls: background checks, onboarding and offboarding paperwork, security training.
  • Vendor risk management and the vendor register.
  • Selecting your auditor, and the audit relationship itself.
  • Acting as your compliance officer or issuing any form of opinion. I'm an engineer, not a CPA firm.

Those belong with your compliance platform, your counsel, or whoever owns the program internally. They tend to go faster once the engineering findings are closed, because most of what a policy asserts is something the infrastructure now actually does.

Why not just run Vanta, or ask an LLM

Both are genuinely useful, and both stop at the same place. Vanta tells you a control is failing. An LLM writes you a policy about it. Neither one logs into your AWS account and closes the security group.

What you're buying here is the fix itself, in your environment, and a named engineer accountable for the remediation, the evidence behind it, and the technical controls it leaves in place.

Deal waiting on a SOC 2?

Tell me what your stack looks like and when the audit window opens. If the diagnostic isn't worth running yet, I'll tell you that, along with a short list of things worth fixing first.

Request the diagnostickeaton@bytecraftco.com