SOC 2 and ISO 27001 readiness in 2026: the engineering work nobody scopes

Summary. A SOC 2 report covers 61 individual criteria across five Trust Services categories, 33 of them under Security alone, and ISO/IEC 27001:2022 lists 93 Annex A controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. A compliance automation platform costs $5,000 to $20,000 a year and collects evidence continuously. What it cannot do is build the systems the evidence comes from. Sprinto's July 2026 cost breakdown puts internal effort at 100 to 200 hours and $5,000 to $20,000 of staff time, on top of $10,000 to $50,000 in Type 2 audit fees, and a first Type 2 needs a three to six month observation window before the auditor can even start testing. That observation window is the deadline that matters, because every day your logging retention is short or an offboarding is manual is a day of evidence you cannot recover later. eCorpIT builds that engineering half. We are ISO 27001:2022 certified and CMMI Level 5 assessed, so this is a road our own senior engineering teams have walked.

The split nobody puts in the plan

Buy Vanta, Drata, Sprinto or Secureframe and you get real value: control mapping, continuous monitoring, an auditor dashboard, and evidence collected without anyone chasing screenshots. That is the collection layer.

Underneath it sits a production layer the platform can only observe. If your identity provider does not deprovision a leaver, the platform will faithfully record that it did not. If your application logs roll off after seven days, the platform will faithfully collect seven days of logs. If nobody has ever restored a backup, the platform has nothing to collect.

Raj Viswanathan, CISO at Nium, puts the consequence plainly: "SOC 2 is an intense, evidence-focused audit. If controls are not automated, it adds more burden to IT teams to ensure we do not miss something. If we miss tracking controls even for a day, it results in control failure, and it will be captured in the report."

A day is the unit. That is why readiness is an engineering project with a start date, not a procurement decision.

Layer	What it covers	Who usually owns it	Can a compliance platform do it
Framework mapping	Criteria to controls to evidence	Compliance platform	Yes
Evidence collection	Screenshots, exports, agent checks	Compliance platform	Yes
Policy library	20 or so security policies	Platform templates plus review	Mostly
Identity and deprovisioning	SSO, MFA, SCIM, access reviews	Platform engineering	No, it can only check
Logging and retention	Centralised logs, retention window	Platform engineering	No
Change management	PR approvals, branch protection, CI/CD least privilege	Engineering	No
Backup and restore proof	Tested restores with dated records	Platform engineering	No
Vulnerability SLAs	Scanning, ownership, time-to-fix evidence	Engineering plus security	No
Infrastructure as code	Provable, reviewable configuration	Platform engineering	No

The rows a platform cannot do are the rows that take a quarter to build. They are also the rows that decide whether your first audit opinion is clean.

What the two frameworks actually ask for

The two standards overlap heavily in engineering terms and differ in structure, so it helps to hold both shapes in mind.

SOC 2 is an AICPA attestation. Its Trust Services Criteria were published in 2017 and the Assurance Services Executive Committee issued revised points of focus in 2022, which updated the guidance rather than the criteria. Security is mandatory and is assessed through the Common Criteria, CC1 to CC9: control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access controls, system operations, change management, and risk mitigation. Availability, Processing Integrity, Confidentiality and Privacy are optional and chosen against what you have promised customers.

ISO/IEC 27001:2022 is a certifiable management system standard. Its Annex A restructured the previous 114 controls into 93, grouped as 37 organizational, 8 people, 14 physical and 34 technological, and introduced 11 new controls.

Dimension	SOC 2	ISO/IEC 27001:2022
Nature	Attestation report by a licensed CPA firm	Certification by an accredited body
Structure	5 categories, 61 individual criteria, 33 under Security	Management system clauses plus 93 Annex A controls
Grouping	Common Criteria CC1 to CC9 plus category criteria	37 organizational, 8 people, 14 physical, 34 technological
Mandatory scope	Security always; other four optional	Full ISMS; Annex A applicability justified in a statement
Time element	Type 1 point-in-time; Type 2 over an observation period	Certification plus surveillance audits
First-cycle duration	Type 1 in 1 to 3 months; Type 2 in 3 to 12 months	Multi-stage audit
Typical trigger	An enterprise buyer's security review	Tender requirements, especially in Europe and India
Renewal shape	Annual, with later Type 2 reports covering 12 months	Ongoing surveillance against the ISMS

For an engineering team the practical consequence is that one body of work satisfies both. Centralised logging with a defined retention window answers SOC 2's CC7 system operations and ISO 27001's technological controls on logging and monitoring. Reviewed pull requests answer CC8 change management and the corresponding secure development controls. Build once, evidence twice.

Where first audits actually fail

Four patterns account for most exceptions, and all four are engineering problems wearing compliance clothes.

Deprovisioning that is a checklist rather than a system. An access review is only as good as the removal that follows it. If a leaver's accounts are removed by hand across eight tools, one will be missed, and the platform will record the miss. SCIM provisioning from a single identity provider, with group membership driving application access, turns a recurring exception into a non-event. The same identity work underpins any serious CIAM and passkeys implementation.

Logs that do not reach back far enough. A Type 2 observation window of three to six months is worthless if application and infrastructure logs are retained for two weeks. There is no retroactive fix. Setting retention correctly is a one-line change; discovering you needed it in month five is a restart.

Restores that have never been run. Availability criteria include backup and recovery testing explicitly, and an auditor wants dated evidence of a restore, not a backup job that reported success. Teams that have never rehearsed a restore usually discover a missing dependency the first time they try.

Change management that lives outside the repository. Auditors increasingly ask who can reach production repositories and deployment workflows, whether repository access is reviewed periodically, whether changes require approval before merge, whether CI/CD workflows run least privilege, whether secrets sit in a secret manager rather than in code or workflow files, whether secret scanning is on, and whether exposed credentials are rotated quickly. Branch protection, required reviewers and a secrets manager answer most of that in a week of work. Retrofitting a year of approvals does not exist as an option. Teams already investing in software supply chain security will find most of this ground already covered.

The current threat data explains why auditors have moved this way. Verizon's May 2026 Data Breach Investigations Report, as cited in Sprinto's July 2026 SOC 2 guide, put vulnerability exploitation at 31% of breaches and third-party involvement at 48%. An auditor asking for time-to-remediate evidence and a vendor inventory is asking about the two largest categories in the data.

Mapping controls to engineering tasks

This is the table to take into sprint planning. Each row is work a compliance platform can verify but not perform.

Control area	SOC 2 anchor	ISO 27001:2022 theme	Engineering task	Evidence it produces
Single sign-on and MFA	CC6 logical access	Technological	One IdP, MFA enforced, no local accounts	IdP policy export, per-user MFA state
Joiner, mover, leaver	CC6 logical access	Organizational and people	SCIM provisioning, group-driven entitlements	Deprovisioning timestamps
Least privilege in cloud	CC6 logical access	Technological	Role separation, break-glass with alerting	IAM policy diffs, break-glass usage log
Centralised logging	CC7 system operations	Technological	Ship app, infra and audit logs to one store with a set retention	Retention configuration, sample queries
Change management	CC8 change management	Technological	Branch protection, required reviewers, deploy approvals	Merged PRs with approvals
Secrets handling	CC6 and CC8	Technological	Secret manager, secret scanning, rotation runbook	Scan results, rotation records
Vulnerability management	CC7 and CC9	Technological	Scanning in CI, severity SLAs, named owners	Ticket ages against SLA
Backup and restore	A1.3 backup and recovery testing	Technological	Scheduled restore drills into an isolated environment	Dated restore reports
Capacity and availability	A1.1 capacity management	Technological	Autoscaling, alerting on saturation	Alert history, capacity reviews
Data classification	C1.1 data classification	Organizational	Tagging in code and storage, retention per class	Classification map, deletion jobs
Vendor and AI tool risk	CC9 risk mitigation	Organizational	Inventory with owner, data access level, risk tier	Reviews, questionnaires, sub-processor list
Infrastructure as code	Across CC6 to CC8	Technological	Terraform or equivalent with reviewed plans	Plan and apply history

The last row is the multiplier. Once configuration lives in code and every change arrives through a reviewed pull request, a large share of the evidence for logical access, change management and configuration baselines becomes a by-product of how you already work. That is the difference between passing an audit and being auditable.

A realistic 12-week readiness sequence

Weeks 1 and 2. Scope. Decide which Trust Services categories you are including, because each one you add brings its own criteria and its own control obligations. Most teams need Security plus Availability and Confidentiality. Write the system description at the same time: the product being audited, in-scope infrastructure and repositories, the identity provider, production repositories and deployment workflows, key vendors and subservice organisations, any AI tools that touch the service, roles and responsibilities, what is excluded and why, the observation period and how evidence will be shared. A vague system description is what generates follow-up questions in month four.

Weeks 3 and 4. Identity. One provider, MFA everywhere, SCIM for the applications that support it, and a documented path for those that do not. Set the access review cadence and run the first one now rather than the week before the audit.

Weeks 5 and 6. Logging and retention. Choose the retention window before the observation period starts, ship application, infrastructure and audit logs to one store, and confirm you can answer "who accessed what, when" with a query rather than a search through several consoles.

Weeks 7 and 8. Change management and secrets. Branch protection, required reviewers, least-privilege CI/CD credentials, secrets moved into a manager, secret scanning enabled on private repositories as well as public ones, and a rotation runbook that has actually been used once.

Weeks 9 and 10. Resilience and vulnerability management. Run a restore into an isolated environment and write down what broke. Put scanning in the pipeline, set severity SLAs, assign owners, and start the clock so there is a trend to show.

Weeks 11 and 12. Vendors, policies and dry run. Build the vendor inventory with business owner, data access level and risk tier, including AI vendors under the same process. Publish the policies. Then run a readiness assessment against your own evidence and fix what it finds, because the same exercise done by the auditor costs a great deal more.

Only after that does the observation window start counting. A first Type 2 needs three to six months of it, and the audit phase itself typically runs four to six weeks. Working backwards from a customer deadline is the only sensible way to plan.

What it costs, and where the money goes

Published ranges vary by size and complexity. Sprinto's July 2026 breakdown gives a usable shape for a smaller organisation: internal effort of 100 to 200 hours costing $5,000 to $20,000 in staff time, automation platforms at $5,000 to $20,000 a year, supporting security tools at $2,000 to $10,000, remediation of control gaps at $1,000 to $10,000, and audit fees of $7,000 to $20,000 for a Type 1 or $10,000 to $50,000 for a Type 2. Totals land around $10,000 to $30,000 for a Type 1 and $20,000 to $70,000 or more for a Type 2.

Read that list again and notice what dominates. The audit fee is the visible number and it is rarely the largest one. Internal effort plus remediation is the engineering half, and it is the half that gets estimated last and overruns first.

There is a second cost nobody lines up: delay. If a first Type 2 needs a three to six month observation window and a deal closes on a report you do not have, the price of missing the start date is the deal, not the audit fee.

India-specific considerations

Indian SaaS and services companies usually meet these frameworks in a specific order. A first enterprise buyer in the United States asks for SOC 2. A European or Indian public-sector tender asks for ISO 27001. A domestic enterprise buyer asks about both and then adds questions about India's Digital Personal Data Protection Act 2023.

The overlap is larger than it looks. SOC 2's Confidentiality and Privacy criteria and ISO 27001's organizational controls both push you toward data classification, retention per class, and provable deletion. Those are the same primitives a DPDP programme needs, and building them once for three audiences is the only sane sequencing. The detail of that work sits in our DPDP engineering playbook for Indian startups, and the budgeting side in the DPDP compliance cost analysis.

Two practical notes for teams operating from India. Audit fees are usually quoted and paid in US dollars regardless of where your engineering sits, so the audit line does not shrink with local salaries even though the internal-effort line does. And a distributed or hybrid workforce raises the difficulty of endpoint and device evidence, which is a control area where a platform genuinely helps once the underlying device management is real.

If your obligations extend into general IT governance rather than product security alone, the wider ground is covered in our corporate IT compliance and auditing guide.

What we actually build

eCorpIT is a Gurugram-based technology consulting company, founded in 2021, working with AWS, Microsoft and Google as partners. We are CMMI Level 5 assessed and ISO 27001:2022 certified. On a readiness engagement, senior-led engineering teams take the rows a compliance platform cannot fill:

Identity and access engineering. Consolidating onto one identity provider, enforcing MFA, wiring SCIM, replacing standing production access with time-bound elevation and an alerting break-glass path.

Logging and evidence pipelines. Centralised log collection with a retention window chosen for the observation period, plus the queries an auditor will ask you to run in front of them.

Change and supply chain controls. Branch protection, required review, least-privilege pipeline credentials, secret management and scanning, and dependency and artefact provenance, connected to our secure development and application security work.

Resilience proof. Restore drills that produce dated evidence, and the capacity and alerting work that Availability criteria expect.

Cloud posture. Least-privilege IAM, configuration baselines in code, and continuous checks, which is the same foundation as our multicloud security posture work.

We design and build systems aligned with SOC 2, ISO 27001 and DPDP requirements. We do not issue attestations and we are not your auditor; a licensed CPA firm performs a SOC 2 audit and an accredited body certifies ISO 27001. Our job is to make sure that when they look, the evidence exists.

Engagements are scoped against the framework and observation window you are targeting rather than a fixed package, because a team with an identity provider already in place needs a fraction of the work of a team with eight tools and local accounts.

FAQ

How many controls do SOC 2 and ISO 27001 actually involve?

SOC 2 spans 61 individual criteria across its five Trust Services categories, with 33 sitting under Security, which is mandatory in every engagement. ISO/IEC 27001:2022 lists 93 Annex A controls grouped into 37 organizational, 8 people, 14 physical and 34 technological, replacing the 114 controls of the previous version.

Can a compliance platform get us audit ready on its own?

No. Platforms such as Vanta, Drata, Sprinto and Secureframe map controls, monitor continuously and collect evidence, which is real value at $5,000 to $20,000 a year. They cannot create the systems the evidence comes from: log retention, SCIM deprovisioning, tested restores, branch protection or least-privilege cloud roles all have to be built.

How long does a first SOC 2 Type 2 take?

Published guidance puts a Type 1 at one to three months and a Type 2 at three to twelve months, because a Type 2 includes a three to six month observation period before the auditor tests operating effectiveness, and the audit phase alone runs about four to six weeks. Subsequent Type 2 reports cover a full twelve-month window.

What does readiness cost?

Sprinto's July 2026 breakdown for smaller organisations gives $5,000 to $20,000 of internal staff time across 100 to 200 hours, $5,000 to $20,000 a year for automation tooling, $2,000 to $10,000 for security tools, $1,000 to $10,000 for remediation, and audit fees of $7,000 to $20,000 for Type 1 or $10,000 to $50,000 for Type 2.

Which Trust Services categories should we include?

Security is required in every SOC 2 engagement. Add Availability if you offer uptime commitments, Processing Integrity if you handle transactions or business-critical processing, Confidentiality if you hold sensitive customer or intellectual property data, and Privacy if you collect personal information. Each addition expands scope, so match the selection to real customer commitments.

Why do first audits usually fail?

Four patterns dominate: manual deprovisioning that misses accounts, log retention shorter than the observation window, backups that have never been restored, and change approvals that live outside the repository. All four produce exceptions that cannot be fixed retroactively, because the missing evidence relates to a period that has already passed.

Does one programme of work cover both frameworks?

Largely, yes. Centralised logging answers SOC 2's system operations criteria and ISO 27001's technological logging controls. Reviewed pull requests answer change management in both. The structures differ, with SOC 2 being an attestation and ISO 27001 a certifiable management system, but the engineering underneath is one body of work.

Is eCorpIT itself certified?

Yes. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 assessed, and works with AWS, Microsoft and Google as partners. We build and audit the engineering controls that support SOC 2, ISO 27001 and DPDP requirements. We do not perform audits or issue attestations, which a licensed CPA firm or an accredited certification body does.

How eCorpIT can help

eCorpIT builds the half of audit readiness a compliance platform cannot: identity and deprovisioning that actually removes access, centralised logging with retention set before the observation window opens, change management enforced in the repository, restore drills that produce dated evidence, and least-privilege cloud roles held in code. Our senior engineering teams work backwards from the date your buyer needs the report, so the observation period starts on time rather than after a scramble. We are CMMI Level 5 assessed and ISO 27001:2022 certified, and we design systems aligned with SOC 2, ISO 27001 and DPDP requirements. If a deal is waiting on a report, talk to us about the gap assessment first, and about the DPDP-ready application work that usually rides alongside it.

References

1. Trust Services Criteria for SOC 2: What You Need to Know — Drata, 28 February 2026
2. SOC 2 Compliance: A Complete Guide for 2026 — Pritesh Vora, Sprinto, updated 9 July 2026
3. Understanding ISO 27001 Controls: A Guide to Annex A — Drata
4. ISO 27001 Annex A Controls List: All 93 Controls by Theme — GAICC
5. ISO 27001:2022 Annex A Controls List — Scrut
6. ISO 27001 Controls: A Guide to Implementing Annex A Controls — Sprinto
7. SOC 2 Trust Services Criteria: A Complete Guide — Bastion
8. Trust Services Criteria (TSCs): SOC 2 Audit Guidance — Linford & Company
9. SOC 2 Trust Services Criteria: Controls and SCF Mappings — Secure Controls Framework
10. Automating ISO 27001 and SOC 2 Evidence Collection in 2026 — SureCloud
11. Maintaining SOC 2 Compliance in 2026 — Scytale
12. Committee of Sponsoring Organizations of the Treadway Commission

Last updated: 3 August 2026.