SOC 2 and NIST readiness for cloud enabled IT organisations and companies

Be audit-ready in weeks, not quarters.

Yubisneeze reads your AWS account, maps what it finds to the criteria an auditor recognizes from SOC2 and NIST, and names exactly what is missing, on day one, not after a quarter of discovery calls. It does not ask for write access without your permission. All reporting and analysis is fully contained in your own control.

first findings

15 minutes

permission required

read-only

frameworks

SOC 2 and NIST

Read-only guaranteeThe scan needs SecurityAudit and ViewOnlyAccess and nothing more. No write permission is requested at any point, and it is enforced in our test suite rather than promised in a sentence — remediation is emitted as infrastructure-as-code you apply yourself. See exactly what we are denied →

Example: SOC 2 Trust Services Criteria

answerable from cloud configuration11 of 36

passing1

failing8

no check written yet — our gap, not yours2

out of reach for a config scanner25 of 36

satisfiable by a document, a person or an integration25

A real screen from the product, fifteen minutes after you create the role. Every band in the bar is named in the rows beneath it, and the groups sum to all 36 criteria — cloud configuration answers roughly a third of SOC 2, so that is the number we show rather than one big percentage with no denominator. Knowing which third, on day one, is what turns your audit from quarters into weeks.

three kinds of evidence, one rule

A criterion passes only when every kind of evidence it requires is in hand.

Clean IAM configuration does not evidence an access-review criterion while nobody has reviewed access in a year. Crediting the automated half alone is how a tool tells a customer they are ready when they are not.

automated

26 cloud checks

Encryption at rest, public buckets, open security groups, root MFA, key age, backup retention, trail integrity. Each one is data, not code, so a new check reaches you as content rather than an upgrade you have to schedule.

attested

26 questions a scanner cannot answer

Has production access been reviewed in the last 90 days? Answers are recorded against a named person, a date and an expiry — because a Type II window tests that the claim was still current at the end of it.

uploaded

10 policies, generated from your estate

The disaster recovery plan names the databases, buckets and regions we actually found, and warns when your estate is single-region. Yours to correct and approve; only an approved, in-date revision counts.

how it works

Four steps, and the first three cost nothing.

Create the role

One CloudFormation template, printed for you to read first. No access key to create and nothing installed in your account.

Scan

About fifteen minutes, runs in AWS CloudShell, costs nothing. Where access is missing you get the exact refused action — ec2:DescribeVolumes, not "the ec2 collector failed".

Read the ledger

Findings by severity, criteria by framework, and a coverage page naming every unit we could not read. Anything undetermined is reported as undetermined.

Deploy it for the team

One command puts the app behind HTTPS in your own account when the results are worth showing to more than one person. It prints the monthly cost before it creates anything.

Step four is the only one that costs anything, and it is your AWS bill rather than ours: roughly 55 USD a month to run the app in your own account. The deploy command prints that figure and asks you to confirm it before it creates anything.

the read-only guarantee

Read-only, and explicitly denied the contents of your data.

The role attaches two AWS-managed policies, SecurityAudit and ViewOnlyAccess — neither contains a single write action — and then explicitly denies reading the contents of your data.

denied	because
s3:GetObject, dynamodb:GetItem, Query, Scan	configuration is enough to assess a control; your objects and rows are not needed
secretsmanager:GetSecretValue, ssm:GetParameter*, kms:Decrypt	we never need a secret or key material, their presence is enough
logs:GetLogEvents, sqs:ReceiveMessage, rds:Download*LogFile	having logging configured is the control, not what the logs say
lambda:GetFunction, codecommit:GetFile	your source code is not evidence
sts:AssumeRole*, sts:GetFederationToken	the role cannot be used in ways beyond your goals and needs with Yubisneeze

The trust policy names a role ARN, not an account root, and requires a per-install external id — so learning your account id is not enough to impersonate our collector. Print the template and diff it before you deploy it. That is what it is for.

yubisneeze role emit | tee role.yaml

what this is not

The limits, stated here rather than found later.

It is not a compliance certificate.

Readiness is not an audit. You will still engage an auditor; this makes that engagement shorter and less surprising.

It does not fix anything for you.

Remediation is emitted as infrastructure-as-code you review and apply. Nothing in the quick-audit scanner has write access to your account.

It does not answer all of SOC 2.

Cloud configuration reaches 11 of 36 criteria. We show you which 25 it cannot reach, named rather than aggregated, instead of quietly scoring them.

Generated policies are drafts.

They are built from your observed configuration, not legal advice. Have counsel or a qualified auditor review the set before anyone relies on them.

coming soon

The beta opens to a small number of AWS accounts.

Tell us where to write. We will send one email with a date in it, and the walkthrough is written so somebody who is not a developer can follow it end to end.