How long does ISO 27001 certification take?

For a mid-sized organisation starting with reasonable IT hygiene but no formal system, the common range is several months rather than several weeks, and the binding constraint is usually not the implementation but the operating period. The system has to run long enough to generate evidence that it works: access reviews performed, incidents logged and closed, training delivered, an internal audit conducted and a management review held. You cannot compress that below the time it takes for those things to actually happen. Organisations already running SOC 2, or with a parent company system to align to, move considerably faster. We give you a realistic sequence after the gap analysis rather than a number before it.

Why do you not publish what this costs?

Because any figure would be wrong for most readers and misleading for the rest. The cost of an ISO 27001 programme is driven almost entirely by scope, by how much already exists, and by how much of the remediation is configuration against work your team has to build. Certification body fees are separate from implementation and are set by the body based on audit days, which is itself a function of your scope and headcount. Numbers published on consultant websites are marketing anchors rather than estimates. We scope first, then tell you what it involves, and we would rather have a shorter conversation about whether you need this at all than an inaccurate one about price.

Can we exclude controls from Annex A?

Yes, and doing so is normal and expected. Annex A is a reference catalogue, not a mandatory checklist. You select controls on the basis of your risk assessment and record the decision in the Statement of Applicability, justifying inclusions against identified risks and exclusions against a defensible reason. An organisation with no in-house software development legitimately excludes secure coding. An organisation with no physical premises in scope excludes most of the physical theme. What auditors will not accept is an exclusion whose justification amounts to finding the control inconvenient, and what makes them suspicious is a Statement of Applicability marking all ninety three controls applicable, which usually signals nobody did the risk assessment.

Does ISO 27001 make us compliant with the DPDP Act?

No, and this is worth being precise about because it is a common and expensive assumption. ISO 27001 gives you an information security management system covering access control, cryptography, logging, incident management and supplier security, which maps well onto the reasonable security safeguards Rule 6 of the DPDP Rules expects. It says nothing about consent, because ISO does not care why you hold data. Notice, purpose-scoped consent, withdrawal, purpose limitation and erasure, data principal rights and the DPDP breach notification clock are all outside its scope. An ISO-certified organisation is meaningfully ahead on DPDP and is not compliant by virtue of the certificate.

Who can be our internal auditor?

Anybody competent and independent of the area they are auditing. It does not have to be a certified lead auditor, and it does not have to be external, though it commonly is for smaller organisations who lack anybody sufficiently separate. What it cannot be is the person who built the system auditing their own work, which is the most common finding we see when we are called in after a failed Stage 2. For a small company the practical options are a suitably senior person from a different function, a peer arrangement with another organisation, or an external internal auditor. We can perform it where we did not implement, and where we did implement we help you arrange somebody independent.

What happens if the auditor raises nonconformities?

It depends whether they are minor or major, and minors are common and not a failure. A minor nonconformity is a lapse that does not undermine the system, and you submit a corrective action plan with root cause and timeline; the certificate can still issue. A major nonconformity is a systemic failure or a complete absence of a required element, and it has to be closed and verified before certification, which usually means a follow-up visit. Going into Stage 2 with no nonconformities at all is unusual. Going in with a major one is normally a sign that Stage 1 findings were not taken seriously.

Do we need to certify our whole company?

No, and you usually should not. Scope is your decision and the certificate states it, so the practical question is what your customers need it to cover. A SaaS business commonly certifies the platform, the teams that build and run it, and the systems that hold customer data, excluding unrelated functions. Certifying everything multiplies audit duration and effort for no commercial gain. The counterweight is that a scope drawn too narrowly is visible on the certificate, and a prospect who reads it and finds their service is outside the boundary is a worse outcome than the extra work would have been. We scope to what the people asking will actually accept.

We already have SOC 2. How much of that carries over?

A great deal, particularly the evidence discipline, which is the hardest habit to build. The control overlap is substantial: access management, change management, logging and monitoring, incident response, vendor management and business continuity all serve both. The gap is structural rather than technical. SOC 2 is an attestation by an auditor about controls over a period; ISO 27001 certifies a management system, so you need the things SOC 2 does not require, a defined scope statement, a formal risk assessment methodology, a Statement of Applicability, an internal audit programme and a management review. Organisations moving from SOC 2 to ISO typically find the second certification meaningfully cheaper than the first was.

Can you do this remotely? We are not in Hyderabad.

Largely yes. Gap analysis, risk workshops, policy development, control implementation on cloud estates and audit preparation are all delivered remotely, and most of our ISO engagements run that way. The exceptions are the physical theme of Annex A, where seeing the premises is more useful than describing them, and the Stage 2 audit itself, where certification bodies vary in how much they will do remotely. We are based in Gachibowli, Hyderabad and work with organisations across India, travelling where the physical scope genuinely requires it. Initial enquiries get a reply within 4 business hours.

ISO 27001, India

ISO 27001 certifies a management system, not a set of controls. That distinction decides whether you pass.

Most failed certification attempts we see went wrong the same way: the organisation treated it as a checklist of ninety three Annex A controls and skipped the management system underneath. Auditors certify against clauses four to ten, the scope, the risk assessment, the objectives, the internal audit, the management review. Annex A is the control set you justify against your own risk assessment, not the thing being certified. We build the system, then the controls it calls for.

Book an ISO 27001 scoping call See what implementation involves

ISO 27001 information security management system implementation in India

93 controlsAnnex A, ISO 27001:2022
Clauses 4-10What is actually certified
3 yearsCertificate validity
Stage 1 and 2How the audit runs

What we build

The management system, then the controls.

ISO 27001:2022 certifies an information security management system. Annex A supplies a catalogue of controls you select from on the basis of your own risk assessment, and the Statement of Applicability records what you chose and why you excluded the rest. Build it in that order and certification is a formality. Build it backwards and the Stage 1 audit tells you so.

Scope, defined narrowly and defensibly

Scope is the first decision and the one most often got wrong in both directions. Too broad and you are certifying systems and teams that have nothing to do with what your customers care about, which multiplies the work and the audit duration. Too narrow and the certificate says something your customers will notice is not what they asked for. We scope to the services, locations, people and systems that carry customer data, and we write the boundary so it survives a question from an auditor and from a prospect reading the certificate.

A risk assessment that drives the controls

The risk assessment is the engine of the whole system. It has to identify risks to confidentiality, integrity and availability, assign owners, evaluate against criteria you defined in advance, and produce a treatment plan. Auditors probe this hard, because a risk register that was clearly written after the controls were chosen is the clearest sign of a system built for the certificate rather than for the business. We run it as a genuine exercise with the people who know where things break.

The Statement of Applicability

Mandatory, and the single document an auditor will spend the most time in. It lists all ninety three Annex A controls, states whether each is applicable, justifies every inclusion against the risk assessment and every exclusion against a reason that is not simply that you did not want to do it, and records implementation status. Exclusions are legitimate and common. Unjustified exclusions are a finding.

Policies people can actually follow

The documented information the standard requires, written to be usable rather than to be long. An information security policy the board has approved, plus the topic-specific policies your risk treatment calls for. We write them against how your organisation actually operates, because a policy describing a process nobody follows is worse than no policy: it is a documented gap, and auditors sample against the document.

The 2022 control set, including the eleven new ones

ISO 27001:2022 restructured Annex A into four themes and introduced eleven new controls that reflect how estates actually look now: threat intelligence, information security for cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. On a Microsoft estate a good share of these are configuration on entitlements you already hold rather than new purchases.

Internal audit and management review

Both are mandatory clauses and both are commonly missing when we are called in after a failed attempt. The internal audit has to be conducted by somebody independent of what they are auditing, cover the whole system across the cycle, and produce findings that get treated. The management review has to demonstrate that leadership actually looked at the system and made decisions. Auditors check for evidence of both, and minutes that were written the week before the audit are recognisable.

Evidence, collected as you go

Certification is an evidence exercise. Access reviews performed and recorded, incidents logged and closed, training completed and attested, supplier assessments carried out, backups tested with results retained, change records showing approval. The organisations that find certification painful are the ones assembling twelve months of evidence in the final month. We set the collection up at the start so the audit is a walkthrough of what already exists.

Certification body selection and audit support

We are not a certification body and cannot certify you, which is a requirement of the scheme rather than a limitation of ours: the body that certifies you must be independent of the consultant who implemented. We help you select an accredited body, prepare for Stage 1 and Stage 2, sit with you through the audit, and handle the findings. Accreditation matters here. A certificate from an unaccredited body is worth considerably less to the enterprise customer who asked for it.

How certification runs

From scoping to certificate, and what happens after.

Durations vary with scope and with how much already exists. This is the shape of the engagement and the sequence auditors expect, rather than a promise about your calendar.

01
Stage A
Scope, gap analysis and risk assessment
Define the boundary, assess what already exists against the clauses and Annex A, and run the risk assessment properly with the people who know the systems. The gap analysis output is a treatment plan with owners and dates, and it is where you find out honestly how far you are.
- Defined and defensible scope
- Gap analysis against clauses 4 to 10 and Annex A
- Risk register with owners and treatment plan
02
Stage B
Build the system and implement controls
Policies written, the Statement of Applicability produced, and the technical controls implemented. On Microsoft estates this is largely configuration: conditional access, device compliance, data loss prevention, logging and retention, privileged access. Elsewhere it is a mix of configuration, process and, occasionally, procurement.
- Approved policy set
- Statement of Applicability covering all 93 controls
- Controls implemented and evidenced
03
Stage C
Operate, internal audit, management review
The system has to run for long enough to generate evidence that it works. Access reviews happen, incidents get logged and closed, training is delivered, suppliers are assessed. Then a full internal audit by somebody independent, findings treated, and a management review with the leadership team.
- Operating evidence across the control set
- Internal audit report with findings closed
- Documented management review
04
Stage D
Stage 1 and Stage 2 certification audit
Stage 1 is a documentation review where the auditor checks the system exists and is ready. Stage 2 is the substantive audit, sampling evidence against the Statement of Applicability. Findings are raised as minor or major nonconformities; minors are corrected with a plan, majors have to be closed before the certificate issues.
- Stage 1 readiness confirmed
- Stage 2 completed and nonconformities closed
- Certificate issued, valid three years
05
Ongoing
Surveillance and recertification
Annual surveillance audits sample parts of the system, and the full cycle repeats at three years. This is where certifications quietly decay: the system stops being operated once the certificate is on the website, and the first surveillance audit finds it. Keeping it alive is much less work than reviving it.
- Annual surveillance audits passed
- Risk assessment refreshed
- Recertification at three years

Why bring us in

Engineers who implement, not auditors who advise.

Microsoft Partner, so most controls are configuration

A large share of the technological theme in Annex A is achievable on entitlements Indian businesses already hold. Access control, cryptography, logging, data leakage prevention, configuration management and secure authentication all map onto Entra, Intune, Purview and Defender. We check your licensing before proposing tooling, and most engagements need no new purchase to close the technical controls.

We implement rather than hand you a plan

A lot of ISO consulting in the Indian market ends at a document pack and a gap register, leaving your team to do the actual configuration with no ISO context. We do the implementation, which is the part that takes real time, and we transfer the operating knowledge as we go so your team can run the system after we leave.

We map controls across frameworks once

If SOC 2, DPDP obligations or customer security questionnaires are also in your future, the underlying controls overlap heavily. We record the control mapping as we build so evidence gathered once serves several purposes, instead of running three separate programmes that each rediscover the same access review.

We are direct about whether you need it

ISO 27001 is the right answer when Indian enterprise buyers, European customers or government procurement are asking, and it is often the wrong first move for a company whose deals are being blocked by American enterprise buyers asking specifically for SOC 2. If your situation points elsewhere we will say so, including when it means a smaller engagement for us.

Who asks for this

What is driving certification, by sector.

SaaS and technology

Procurement gates. ISO 27001 is the certification Indian enterprise, European and UK buyers ask for by name, and it appears in RFP scoring as a pass or fail line rather than as a preference.

BFSI and fintech

Frequently already carrying sectoral obligations, so the controls largely exist and the work is assembling them into a management system with the clauses the standard requires around them.

Manufacturing and engineering

Customer-driven, usually by an OEM or a European client extending supply chain security requirements down to their vendors. Scope discipline matters most here, because certifying every plant is rarely what anybody actually asked for.

Healthcare and life sciences

Partner and sponsor requirements, particularly for anybody handling clinical trial or patient data on behalf of an international organisation. Overlaps substantially with the DPDP work most of these organisations also have ahead.

BPO and shared services

Contractual, and often written into the master services agreement with a date attached. The scope conversation is usually about which delivery centres and which client accounts are inside the boundary.

GCCs

Parent company mandate, sometimes to align an Indian entity with a group certification and sometimes to certify independently. Group alignment is materially less work if the parent will share their system, and worth asking about before starting from scratch.

Where attempts fail

The six findings that stop a certification, and how to avoid each.

We are frequently brought in after a failed Stage 1 or Stage 2, and the causes repeat. None of them are exotic and none are about the technical controls, which is the part most organisations worry about most. They are all about the management system underneath.

A risk assessment written after the controls

The most common structural failure. The organisation decided which controls to implement, then produced a risk register that justifies them. Auditors recognise this immediately, because the risks map one to one onto the controls with nothing left over and nothing accepted.

Run the assessment before choosing controls, with the people who know the estate
Expect some risks you decide to accept rather than treat, and record why
Assign each risk a named owner who can speak to it in the audit

A Statement of Applicability marking everything applicable

Applying all ninety three controls looks thorough and reads as evasive, because it signals that nobody performed the selection the standard asks for. It also commits you to evidencing controls that have nothing to do with your business.

Exclusions are normal and expected when justified against the risk assessment
A software company with no in-house development legitimately excludes secure coding
Justify inclusions against identified risks, not against the control existing

An internal audit performed by the person who built the system

A mandatory clause, and the one most often failed on independence rather than on absence. Somebody auditing their own work is not an internal audit, and it is a finding the auditor raises without needing to look at the content.

Use a senior person from an unrelated function where you have one
A peer arrangement with another organisation works well for small companies
An external internal auditor is legitimate, provided they did not implement

Policies describing an organisation that does not exist

Template policies adopted unchanged describe an idealised company with roles you do not have and processes you do not follow. Auditors sample against the document, so an aspirational policy is a documented gap rather than a head start.

Write against how the organisation actually operates today
Where a policy describes a future state, say so and give it a date
Fewer, shorter, followed policies beat a comprehensive set nobody reads

Evidence assembled in the final month

The system has to have operated, and operation leaves traces across the period rather than at the end of it. Access reviews dated within a fortnight of the audit tell the auditor exactly when the system started running.

Set evidence collection up at the start, not before the audit
Access reviews, training records, supplier assessments and incident logs across the period
A backup restore test with a result, not a backup policy

A system that stops the day the certificate arrives

The quietest failure, and it surfaces at the first surveillance audit roughly a year later. Reviews lapse, the risk assessment is never revisited, and the management review never happens again. Reviving a dormant system costs more than maintaining it.

Put the recurring obligations in the calendar with named owners before you certify
Refresh the risk assessment on a schedule and after any significant change
Treat the surveillance audit as the deadline it is, not as a formality

Two ways this gets done

Certificate-first implementation against a system that actually runs.

Both approaches end with a certificate. Only one survives the first surveillance audit, and only one gives you anything beyond a logo. The difference shows up about fourteen months in.

Feature	Dimension	Certificate-first
Starting point	A template policy pack, adapted	Scope and a real risk assessment
Risk register	Written to justify controls already chosen	Drives which controls are selected
Statement of Applicability	Everything marked applicable to be safe	Justified inclusions and defensible exclusions
Policies	Describe an idealised organisation	Describe how you actually work
Evidence	Assembled in the final month	Accumulates from the start
Internal audit	Performed by whoever built the system	Independent of the area being audited
First surveillance audit	Finds the system stopped being operated	Routine, because it never stopped
Value beyond the logo	None, and the risk profile is unchanged	Actual reduction in the things that cause incidents

We cannot certify you, and neither can anybody who implements for you.

The certification body has to be independent of the consultant who built your system. Any provider offering to both implement and certify is either not an accredited certification body or is proposing something that undermines the value of the certificate you are buying. We implement, we prepare you, we sit with you through the audit, and an accredited body separate from us issues the certificate. Accreditation is worth checking too, because a certificate from an unaccredited body will be questioned by exactly the enterprise customers who asked you to get one.

Check the certification body is accredited by a recognised national accreditation body
Ask a prospective body for their accreditation scope, it has to cover ISO 27001 and your sector
Treat any offer to implement and certify together as a warning sign
The certificate names the scope, so a prospect will read the boundary you defined

Working with us

What the engagement looks like.

1
Scoping conversation before anything is quoted
What is driving the requirement, who asked for it, what the certificate has to say, and which parts of the business genuinely need to be inside the boundary. This determines the size of everything downstream, and getting it right is the highest-leverage hour in the project.
2
Gap analysis against the clauses and Annex A
An honest assessment of what exists against what is required, delivered as a treatment plan with owners, effort and dependencies rather than as a score. Organisations with mature IT are often further along than they expect on the technical controls and further behind on the management system.
3
Risk assessment run with your people
Workshops with the teams who know where things actually break, producing a risk register that reflects the business rather than a generic threat list. This is the document that has to hold up under questioning, and it only does that if it came from people who know the estate.
4
Build, implement, and start collecting evidence
Policies written, Statement of Applicability produced, controls configured. Evidence collection set up from day one so the audit is a walkthrough rather than an archaeology exercise. Your team is involved throughout, because they have to operate this afterwards.
5
Internal audit, management review, then the certification audit
A genuine internal audit by somebody independent, findings treated, and a management review that demonstrates leadership engagement. Then Stage 1, remediation of anything it raises, Stage 2, and support through closing any nonconformities.

Questions we get asked

ISO 27001, answered plainly.

Around this decision.

SOC 2 vs ISO 27001

Which one your buyers actually want, what each proves, and why the answer usually follows the geography of your pipeline rather than the merits of the frameworks.

Learn more

SOC 2 readiness

The American attestation, the Type 1 and Type 2 distinction, and the observation window that decides your timeline.

Learn more

Audit readiness assessment

A standalone gap analysis if you want to know where you stand before committing to a certification programme.

Learn more

Next step

Start with scope, not with a template.

Tell us who asked for the certificate and what it has to cover, and we will tell you what implementation actually involves for your estate. If the honest answer is that SOC 2 serves your pipeline better, we will say that too. Remote-first from Hyderabad, serving all of India.

Book an ISO 27001 scoping call Compare SOC 2 and ISO 27001

Related Services

Explore more solutions that work great with this service

ISO 27001 certifies a management system, not a set of controls. That distinction decides whether you pass.

The management system, then the controls.

Scope, defined narrowly and defensibly

A risk assessment that drives the controls

The Statement of Applicability

Policies people can actually follow

The 2022 control set, including the eleven new ones

Internal audit and management review

Evidence, collected as you go

Certification body selection and audit support

From scoping to certificate, and what happens after.

Scope, gap analysis and risk assessment

Build the system and implement controls

Operate, internal audit, management review

Stage 1 and Stage 2 certification audit

Surveillance and recertification

Engineers who implement, not auditors who advise.

Microsoft Partner, so most controls are configuration

We implement rather than hand you a plan

We map controls across frameworks once

We are direct about whether you need it

What is driving certification, by sector.

SaaS and technology

BFSI and fintech

Manufacturing and engineering

Healthcare and life sciences

BPO and shared services

GCCs

The six findings that stop a certification, and how to avoid each.

A risk assessment written after the controls

A Statement of Applicability marking everything applicable

An internal audit performed by the person who built the system

Policies describing an organisation that does not exist

Evidence assembled in the final month

A system that stops the day the certificate arrives

Certificate-first implementation against a system that actually runs.

We cannot certify you, and neither can anybody who implements for you.

What the engagement looks like.

Scoping conversation before anything is quoted

Gap analysis against the clauses and Annex A

Risk assessment run with your people

Build, implement, and start collecting evidence

Internal audit, management review, then the certification audit

ISO 27001, answered plainly.

How long does ISO 27001 certification take?

Why do you not publish what this costs?

What changed in ISO 27001:2022 compared to the 2013 version?

Can we exclude controls from Annex A?

Does ISO 27001 make us compliant with the DPDP Act?

Who can be our internal auditor?

What happens if the auditor raises nonconformities?

Do we need to certify our whole company?

We already have SOC 2. How much of that carries over?

Can you do this remotely? We are not in Hyderabad.

Around this decision.

SOC 2 vs ISO 27001

SOC 2 readiness

Audit readiness assessment

Start with scope, not with a template.

Related Services

SOC 2 Readiness

Audit Readiness Assessment

Security Questionnaire Response

DPDP Act Compliance