What a SOC 2 report is, for a Lakshadweep company
- Framework ownerAICPA, Trust Services Criteria (TSP section 100)
- Who signs itAn independent licensed CPA firm, never a consultant
- Local filingNone in Lakshadweep or anywhere in India
- DistributionRestricted use, under NDA; SOC 3 for public use
The distinction between attestation and certification matters more than it sounds. There is no accreditation body, no certificate number to verify and no registry to look you up in. What a buyer receives is a document with an auditor's opinion attached to your own description of your system. That is why two SOC 2 reports from two companies in Lakshadweep can look entirely different: the scope, the criteria and the description are yours, and the opinion speaks only to what you put in them.
It also explains how reports get read. A sophisticated buyer looks at the system boundary before the opinion, checks which criteria were included, notes the window length, and reads the exceptions and management responses. A report covering a narrow slice of your platform for a one-month window answers less than it appears to.
Audit ready What readiness produces
The deliverables below exist so that fieldwork audits a working system rather than a scramble. They are also what a security questionnaire asks for months before any report exists.
- Scope statement: criteria, system boundary, locations and subservice organisations
- Gap assessment against the common criteria CC1 to CC9, with owners
- Control matrix mapping each criterion to a control, an owner and its evidence
- Policy set and the system description drafted to the description criteria
- Evidence pipeline and a recurring control calendar
- Internal test results, so nothing fails for the first time in fieldwork
Who can and cannot sign your report
Only a licensed CPA firm, independent of your company, can perform the examination and issue the report, and it need not be located in India. That independence is a professional requirement, which is why the firm preparing you cannot also audit you. IncorpX does the readiness work in Lakshadweep and helps you select and brief the CPA firm; the opinion is theirs alone.
The five Trust Services Criteria
Security is mandatory. The other four are chosen against what you promise customers, because every category added is examined and every category skipped is one a buyer may ask about.
| Category | What it covers | Include it when |
|---|---|---|
| Security (common criteria) | Protection against unauthorised access, disclosure and damage: governance, risk assessment, access, operations, change management, risk mitigation | Always. Every SOC 2 includes it |
| Availability | The system is available for operation and use as committed, including capacity, monitoring, backup and recovery | You commit to uptime or a recovery objective in contracts or an SLA |
| Processing Integrity | Processing is complete, valid, accurate, timely and authorised | The accuracy of your output is the service, as in payments, payroll or analytics |
| Confidentiality | Information designated as confidential is protected as committed, including retention and disposal | You hold customer confidential data under NDA or contractual confidentiality terms |
| Privacy | Personal information is collected, used, retained, disclosed and disposed of in line with your privacy notice | A buyer specifically asks, and your privacy programme is already in place |
Inside Security, the common criteria run from CC1 to CC9. CC1 to CC5 follow the COSO internal control framework: control environment, communication and information, risk assessment, monitoring activities and control activities. CC6 covers logical and physical access, which for a team in Lakshadweep includes office access and device control as well as cloud identity. CC7 covers system operations including monitoring, incident response and vulnerability management. CC8 covers change management, CC9 risk mitigation including vendor management. That structure is why a SOC 2 programme touches HR, engineering, IT and procurement rather than sitting in one team.
Adding Privacy is a bigger decision than it looks
The Privacy category examines your handling of personal information against your own privacy notice, so the notice has to be accurate before it can be audited. Companies that add Privacy without a working privacy programme end up fixing notices, retention and rights handling under audit pressure. If the GDPR or the DPDP framework already applies to you, build that programme first and let the SOC 2 Privacy category follow it.
Scope, system boundary and delivery locations
Scope is the cheapest thing to get right and the most expensive to fix later. It decides your fee, your evidence load and what the report is worth to a buyer.
Products and environments
Which product lines, environments and cloud accounts sit inside the boundary. Shared corporate infrastructure widens scope quickly.
People and locations
Every place in-scope systems are operated or accessed: your Lakshadweep offices, remote staff elsewhere in Lakshadweep, and contractors.
Subservice organisations
Cloud and platform providers are normally carved out, with the controls you expect them to operate named in your description.
User entity controls
Controls your customers must operate for yours to work, listed so a reader sees exactly where responsibility transfers.
Carve-out is the normal answer
Under the carve-out method, your cloud provider's controls sit outside your examination and its own SOC report is relied on, while your description names the controls you expect it to operate. The inclusive method pulls the provider into your engagement and needs its participation, which hyperscale providers do not give. Carve-out is not a weakness; it is how the standard expects a modern stack to be described.
What an auditor actually tests
Type 2 fieldwork is sampling. The auditor asks for a population, picks items from it and traces each one end to end. Evidence that cannot produce a population is not evidence.
| Control area | Evidence the auditor samples | What usually goes wrong |
|---|---|---|
| Access provisioning | Joiner tickets with approval, matched to identity provider records | Access granted in chat and approved later, or never |
| Access removal | Leaver tickets with timestamps against last login and revocation records | Offboarding that lags by days, especially for contractors |
| Periodic access review | Signed review records per system, per period | A quarter skipped during a busy release cycle |
| Change management | Change tickets linked to merges, with approval and test evidence | Hotfixes shipped outside the process with no retrospective ticket |
| Vulnerability management | Scan output plus remediation records against your stated SLA | Findings tracked in a spreadsheet with no closure dates |
| Incident response | Incident tickets showing detection, triage, resolution and review | Incidents handled in a channel and never ticketed |
| Backup and recovery | Backup logs and a documented restore test inside the period | Backups running, restores never tested |
| Vendor management | Vendor list with risk ratings and review records | New sub-processors added without review |
| Security training | Completion records for all in-scope staff | New joiners missed between training cycles |
| Physical access | Office access records for the Lakshadweep premises, reviewed periodically | Visitor and badge records kept informally, or not at all |
| Monitoring and alerting | Alert-to-resolution trails for sampled alerts | Alerts acknowledged with no record of what was done |
| Management oversight | Minutes showing security matters reviewed | Oversight that happens verbally and is never minuted |
How a Lakshadweep company gets SOC 2 ready
Ten steps in dependency order. Readiness runs 8 to 12 weeks for a single-product team, then the observation window and fieldwork follow.
Confirm what the buyer asked for
Some procurement teams accept a Type 1 as an interim step; others wait for a Type 2 with a stated window. The answer decides your timeline, your criteria and whether the window opens this quarter or after a month of control work.
Fix the criteria and the system boundary
Security is mandatory. Add Availability where you commit to uptime, Confidentiality where you hold data under NDA, Processing Integrity where accuracy is the service, Privacy only on request. Then draw the boundary across products, environments, teams and Lakshadweep locations.
Run the gap assessment
Test the current state against CC1 to CC9 and any added categories, covering governance, risk assessment, logical and physical access, system operations, change management and risk mitigation. The output is a prioritised gap list with named owners.
Design controls that match how the team works
Write controls to the way your engineers operate, then tighten the operation, rather than adopting an aspirational policy nobody follows. A control described more strictly than it runs is the most common source of exceptions in a Type 2.
Build the policy set and system description
Produce the policies the criteria expect: access control, change management, incident response, vendor management, business continuity, secure development and more. Draft the system description against the AICPA description criteria, since the opinion attaches to it.
Set up the evidence pipeline and control calendar
For every control, decide how evidence is produced, where it lives and who owns it: tickets with approvals, access review records, scan and remediation logs, restore tests, training records, vendor reviews. Put recurring controls on a calendar.
Select and brief the CPA firm
Only a licensed, independent CPA firm can perform the examination under AT-C 105 and 205, and it need not be in India. Compare proposals on scope, criteria, window length, fieldwork approach and reporting timeline, then brief the firm with your description and control matrix.
Test internally, then open the window
Run your own sample tests against every control before the window opens. Anything failing internally will fail in fieldwork, and a failure inside the window stays inside the reported period. Open the window only once controls have genuinely been running.
Operate through the observation period
Three months for a first Type 2, six to twelve once established. Operate the controls, collect evidence as it happens rather than reconstructing it later, and log every deviation with a management response so nothing surprises anyone in fieldwork.
Complete fieldwork and plan the next cycle
Support the auditor's sampling, answer requests quickly, and respond to exceptions with a remediation plan. Once the report is issued, open the next window immediately, keep controls running, and issue bridge letters to buyers who ask in the gap.
Find out how far your Lakshadweep team is from a clean Type 2
A readiness review maps your current controls against the common criteria, tells you which criteria belong in your report, and gives you the gap list with owners before any auditor is engaged.
Windows, validity and the annual cycle
SOC 2 has no expiry date printed on it, but the market behaves as though it does. These are the timings that decide when your report stops answering questions.
| Stage | Typical duration | What is happening |
|---|---|---|
| Readiness | 8 to 12 weeks | Scoping, gap assessment, control design, policies, evidence pipeline, internal testing |
| Type 1 examination, if used | 2 to 4 weeks | Auditor examines design at a point in time and issues the report |
| Observation window, first Type 2 | 3 months | Controls operate and evidence accumulates across the stated period |
| Observation window, mature cycle | 6 to 12 months | Continuous coverage, each window starting where the last ended |
| Fieldwork and reporting | 4 to 8 weeks | Sampling, testing, exceptions, management responses and report issuance |
| Practical report shelf life | About 12 months | Buyers expect a period ending within the last year |
| Bridge letter coverage | Up to about 3 months | Management letter covering the gap between period end and today |
Plan the window backwards from the deal
If a contract closes in June and the buyer wants a Type 2, a three month window has to open in roughly February, which means readiness in Lakshadweep starts in November. Teams that start when the buyer asks are always a quarter late. The cheapest fix is to open a window as soon as controls are running, even before a specific deal needs it, because an in-progress window is itself an answer procurement will accept.
What produces a clean report, and what produces exceptions
Nearly every exception traces back to one of these, and nearly every one is cheaper to fix before the window than during fieldwork.
Produces a clean opinion
- Controls written to match how the team actually works, then tightened deliberately
- Access reviews on a calendar with a named owner, completed every period without exception
- Change management that covers hotfixes, with a retrospective ticket where speed demanded it
- Evidence produced as a by-product of work: tickets, approvals and logs with dates attached
- A restore test actually performed inside the window, not merely scheduled
- Vendor reviews that happen when a vendor is added, not once a year in a batch
- Deviations logged with a management response as they occur
Produces exceptions
- Aspirational policies copied from a template that describe a company you are not
- A window opened before controls were genuinely operating
- Access reviews skipped in the busiest quarter, discovered during sampling
- Offboarding evidence that cannot be tied to a leaving date
- Screenshots with no timestamps, offered where a ticket population was requested
- New sub-processors added mid-window with no review record
- Scope quietly widened by a new product without updating the description
SOC 2 vs ISO 27001 vs the privacy laws
They answer different questions, and enterprise buyers increasingly ask all three. One control programme can feed all of them if it is built that way.
| Dimension | SOC 2 | ISO 27001 | GDPR and DPDP |
|---|---|---|---|
| What it is | An auditor's report on controls | A certifiable management system standard | Statutory obligations |
| Who signs off | A licensed CPA firm | An accredited certification body | Nobody: you evidence compliance yourself |
| Output | Restricted-use report, shared under NDA | A certificate valid three years with surveillance audits | An evidence pack you produce on demand |
| Scope defined by | Your system description and chosen criteria | Your ISMS scope statement and statement of applicability | The personal data you actually process |
| Time to first result | Readiness plus window plus fieldwork | Typically 4 to 8 months to certification | 4 to 8 weeks for a first programme |
| Preferred by | North American technology buyers | European and global enterprise buyers | Regulators, and any buyer handling personal data |
| Recurs | Annually, by window | Surveillance annually, recertification every three years | Continuously, reviewed on change |
The overlap is real but partial. One risk assessment, one access review process, one change workflow and one evidence pipeline can serve SOC 2 and ISO 27001 at once for a team in Lakshadweep. Neither, however, gives you a lawful basis, a privacy notice, a data processing agreement or an EU transfer file, which is why companies selling into Europe run a GDPR programme alongside rather than instead.
SOC 2 terms, defined
The vocabulary auditors and procurement teams use, in the sense the AICPA framework gives it.
- Service organisation
- The entity being examined, providing services to user entities. In a SOC 2 that is your company in Lakshadweep, and the report describes the system through which those services are delivered.
- User entity
- Your customer: the organisation using your service, whose management and auditors are the intended readers of the report.
- Subservice organisation
- A vendor you rely on to deliver the service, typically a cloud or platform provider. Normally carved out of your examination, with its own SOC report relied on.
- Common criteria
- Criteria CC1 to CC9, the Security category present in every SOC 2. CC1 to CC5 follow the COSO framework; CC6 to CC9 cover access, operations, change and risk mitigation.
- Points of focus
- Illustrative considerations published with the criteria describing characteristics of controls that meet them. The 2022 revision updated them for cloud infrastructure, remote working and current threats without changing the criteria.
- Observation window
- The stated period a Type 2 report covers, during which controls must operate and evidence must accumulate. Commonly three months for a first report, then six to twelve.
- Exception
- A test result showing a control did not operate as described. Reported with management's response, and material mainly when it forms a pattern or goes unremediated.
- Restricted use
- The distribution limit on a SOC 2 report: management, customers and their auditors, under NDA. Public distribution requires a SOC 3 derived from the same examination.
SOC 2 guides and resources
Deeper reading on the Trust Services Criteria, how SOC 2 compares with ISO 27001, the security stack Indian startups build for enterprise sales, and the privacy frameworks that sit alongside the audit.
FAQs about SOC 2 compliance in Lakshadweep
34 questions taken from real search queries, enterprise security questionnaires, AICPA guidance and the way examinations actually run.
Get the controls right, and the report follows
Our security compliance experts scope your criteria and system boundary, close the gaps against the common criteria, build the evidence pipeline in your Lakshadweep team, and hand you to a licensed CPA firm ready for the window.
Nebin Binoy 
