IAM reduction
Wildcard policies narrowed against what was actually called in the last ninety days, unused users and keys removed, break-glass access documented.
IAM cleanup, encryption, audit trails, and the evidence collection that turns an enterprise security questionnaire from a two-week scramble into an afternoon.
SOC 2 compliance on AWS means proving that the controls you claim (access control, encryption, logging, change management) actually ran for the whole observation window your auditor sets. AWS secures the infrastructure underneath. Everything you configure on top of it is yours to evidence.
Teams usually have more controls than they can prove. The audit hurts because nobody is collecting the screenshots, the logs and the change records on the way past. Automate the collection once and the second audit costs a fraction of the first.
Wildcard policies narrowed against what was actually called in the last ninety days, unused users and keys removed, break-glass access documented.
At rest and in transit, with KMS key policies that say who can decrypt what, and rotation that happens without a calendar reminder.
CloudTrail to a locked account, Config rules for drift, GuardDuty findings routed to somebody rather than to a dashboard.
The artifacts an auditor asks for, produced on a schedule and stored where you can find them a year later.
We answer the AWS half of the security questionnaire your prospect sent, with the technical detail attached.
Most teams have more controls than they can prove, so evidence is the bulk of the job.
Which framework, which systems are in scope, and what evidence already exists. The gap list is usually shorter than the fear.
Policies narrowed against ninety days of recorded access, unused users and keys removed, break-glass access documented and tested.
KMS key policies that say who can decrypt what, CloudTrail to a locked account, Config rules for drift, GuardDuty findings routed to a person.
The artifacts an auditor asks for, produced on a schedule and stored where you can still find them a year later.
Walk the evidence the way an auditor will and fix what is thin. After that we answer the AWS half of buyer questionnaires as they arrive.
Most teams need one of the two, not both, and which one is usually decided by who is asking for it rather than by anything technical.
| Dimension | SOC 2 | ISO 27001 |
|---|---|---|
| What the buyer receives | An auditor report describing controls and any exceptions | A certificate, plus the statement of applicability if you share it |
| Who usually asks | North American buyers, mostly SaaS procurement | European and enterprise buyers, and public tenders |
| Scope is set by | You, picking which trust services criteria apply | The standard, with exclusions justified in writing |
| Time to first report | Type I in weeks, Type II after a 3-12 month window | Typically 6-12 months including the stage 1 and stage 2 audits |
| Renewal | Annual, and buyers expect an unbroken run of windows | Surveillance audits each year, full recertification at three |
| AWS work involved | Largely the same either way: IAM, encryption, logging, evidence | Same technical work, more documentation of the management system |
If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.
No, and that separation matters. We do the engineering and prepare the evidence, your auditor does the audit. We have worked alongside most of the common SOC 2 platforms.
For a team already running on AWS with reasonable hygiene, the technical work is typically six to ten weeks. The observation window afterwards is set by your auditor, not by us.
AWS is audited for the parts it runs: data centres, hardware, the hypervisor. It hands you those reports through AWS Artifact. Your auditor will not test any of that. They will test what you configured: who can reach production, what is encrypted, what is logged, and whether changes were reviewed.
Whichever your buyers ask for. North American SaaS procurement usually asks for SOC 2, European and public-sector buyers usually ask for ISO 27001. The AWS engineering underneath is close to identical, so starting the technical work does not commit you to one.
No. The AWS report covers AWS. Your auditor will accept it as evidence that the infrastructure layer is controlled, then ask you for evidence of everything you built on top. Downloading it from AWS Artifact is a step in your audit, not a substitute for it.
Access reviews showing who had production access and when it was last checked, CloudTrail logs proving the review happened, change records tying a deploy to an approval, encryption settings, backup restore tests, and onboarding and offboarding records. We automate the collection so the second audit is cheaper than the first.
It can, which is why we narrow policies against ninety days of recorded access rather than against a guess. Anything a role genuinely called stays. We stage the change per role and keep a documented break-glass path so nobody is locked out of production during an incident.
It depends on the size of the account and how much IAM history there is to unwind, so we scope it before quoting. Ask on the call and we will give you a fixed fee for the technical work. Auditor fees and any compliance platform subscription are billed to you directly by those vendors, not by us.
A two-week read of your AWS account against the six pillars. You get a ranked list of what to fix, what it costs, and what happens if you leave it.
Pool, silo and bridge tenancy models on AWS, with per-tenant limits, isolation you can prove to an auditor, and cost attribution that adds up.
Terraform, deployment pipelines and environments that rebuild from code. Deploys a new hire can run in their first week without supervision.
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.