ISO 27001: Information Security Management

ISO 27001: Information Security Management

ISO/IEC 27001:2022 is the internationally recognised standard for building and operating an Information Security Management System (ISMS). For an Indian organisation seeking certification in FY 2026-27, it requires a scoped, risk-driven set of 93 controls, a documented Statement of Applicability, board-level ownership, and a two-stage audit by an accredited certification body. With the Digital Personal Data Protection Act, 2023 (DPDP Act) operational and CERT-In six-hour incident-reporting timelines in effect, ISO 27001 certification has shifted from a sales credential to a foundational risk control.

What ISO 27001:2022 Actually Demands — a System, Not a Policy Library

The 2022 revision, published in October 2022, is built around one central idea: information security must be managed as a system, not as a collection of policies on a shared drive. The standard follows ISO's Harmonized Structure (HS), meaning its core clauses mirror ISO 9001, ISO 14001, and other management system standards. If your organisation already holds one of these certifications, the governance and audit methodology overlaps significantly.

The mandatory requirements fall across eight clauses:

• Clause 4 — Context: Identify internal and external issues, interested parties, and applicable legal requirements — including the DPDP Act, Information Technology Act 2000, sector-specific regulations (RBI Master Direction on IT, IRDAI cyber guidelines, SEBI CSCRF), and any contractual obligations.
• Clause 5 — Leadership: Top management must sign and communicate an ISMS policy, assign roles, and demonstrate active engagement. An annual board briefing on information security risk, with minutes, is the minimum evidence auditors expect.
• Clause 6 — Planning: Conduct a formal risk assessment, decide on treatment options, and produce a risk treatment plan. The Statement of Applicability (SoA) is created and owned here.
• Clause 7 — Support: Define resources, required competencies, awareness training programmes, and document control procedures including version management and access rights to the document repository.
• Clause 8 — Operation: Implement the controls selected in the SoA, manage operational security events, and govern supplier and third-party relationships.
• Clause 9 — Performance Evaluation: Internal audits, management reviews, and ISMS key performance indicators (KPIs) such as mean time to detect, patch cycle completion rates, and access review completion.
• Clause 10 — Improvement: Corrective action processes and the continual improvement cycle.

One critical clarification: the Annex A controls are not individually mandatory. Any control can be excluded, provided your SoA contains a documented, risk-based justification for that exclusion and confirms the excluded control does not leave unacceptable residual risk. What is non-negotiable is the rigour of the risk assessment process that drives those decisions.

The 93 Annex A Controls: What the 2022 Edition Changed

The 2013 edition contained 114 controls across 14 domains. The 2022 edition reorganised these into 93 controls across four themes:

The Eleven New Controls You Cannot Ignore

The 2022 edition introduced eleven controls absent from the 2013 standard. These are the most likely sources of non-conformity for organisations migrating, and the most scrutinised areas for new certifications:

1. 5.7 Threat intelligence — Collect and analyse information about threats to inform risk decisions. Subscribing to CERT-In advisories and at least one commercial threat feed, with documented review, constitutes evidence.
2. 5.23 Information security for use of cloud services — A documented cloud security policy covering shared responsibility models, data residency requirements, and exit or portability provisions. Applicable to virtually every Indian IT company using AWS, Azure, GCP, or Oracle Cloud.
3. 5.30 ICT readiness for business continuity — Explicitly ties your ISMS to your business continuity plan. If you hold ISO 22301 certification, reference it here; if not, you need at minimum a documented IT continuity plan with tested recovery objectives.
4. 7.4 Physical security monitoring — CCTV coverage, visitor access logs, and alarm systems, with documented review procedures and periodic testing records.
5. 8.9 Configuration management — Documented baseline configurations for servers, endpoints, network devices, and cloud workloads, plus evidence of drift detection and remediation. Auditors ask to see actual baseline documents, not just a policy stating that baselines exist.
6. 8.10 Information deletion — Written procedures for secure deletion of data when the purpose of processing ends. Directly relevant to DPDP Act Section 8(7), which requires data fiduciaries to erase personal data once the purpose is fulfilled.
7. 8.11 Data masking — Masking or pseudonymisation of personal and sensitive data in non-production environments (development, testing, UAT). This is a critical gap for software companies that routinely copy live customer data into test environments.
8. 8.12 Data leakage prevention (DLP) — DLP controls on endpoints, email gateways, and removable media. These do not have to be enterprise DLP tools — compensating controls with documented rationale are acceptable for smaller scopes.
9. 8.16 Monitoring activities — SIEM or centralised log management with defined detection use cases, alert thresholds, and evidence of alert review and response.
10. 8.23 Web filtering — Controls to restrict access to malicious or inappropriate websites from within the ISMS scope.
11. 8.28 Secure coding — A documented secure software development lifecycle (SDLC), including code review gates, security testing requirements, and secure coding standards. Critical for any software development scope.

Transition note: The deadline to migrate certificates from ISO 27001:2013 to ISO 27001:2022 was 31 October 2025. As of FY 2026-27, any certificate still referencing the 2013 standard is expired or non-conforming. If your organisation has not yet completed the transition, this is an urgent remediation priority.

Scoping Your ISMS: The Decision That Determines Everything

The ISMS scope defines the boundary of what the standard covers and therefore what the auditor examines. Under-scoping undermines credibility; over-scoping stretches resources and timelines unnecessarily. The scope must be defensible to a reasonable auditor who understands your business model.

Common scopes for Indian organisations:

• Product-specific: "Development, delivery, and support of [Product Name], including the cloud infrastructure hosted on AWS Mumbai region (ap-south-1)."
• Entity-wide: "All information assets of [Company Name], including its Bengaluru registered office and employees working remotely across India."
• Service-delivery: "IT-enabled services delivered to clients under the BPM vertical, from the Chennai delivery centre."

The scope statement must identify all interfaces and dependencies with functions outside the ISMS boundary. If your corporate IT team manages the network but sits outside scope, you need documented agreements with them that address your security requirements — and those agreements will be reviewed by the auditor.

One principle that has become non-negotiable in 2026: if personal data of Indian residents is processed within the ISMS scope, the controls must satisfy both ISO 27001 and the DPDP Act simultaneously. Scoping out the data-processing function to reduce the audit surface is not a strategy; it is a risk transfer to the board.

The Statement of Applicability: Writing One That Holds Up Under Audit

The Statement of Applicability (SoA) is the most scrutinised document in an ISO 27001 certification audit. Every certification body auditor will review it during Stage 1. A poorly built SoA is the most common reason Stage 1 reviews generate major observations that delay Stage 2.

A compliant SoA must, for each of the 93 Annex A controls:

1. State whether the control is applicable or excluded
2. If applicable, provide the inclusion justification — legal/regulatory requirement, risk treatment decision, contractual obligation, or business objective
3. If excluded, provide a written justification and confirm the exclusion does not introduce unacceptable residual risk
4. Reference the implementing document or evidence — the policy, procedure, technical configuration, or record that proves the control is operational

Build the SoA as a spreadsheet with columns for: control number, control name, applicable/excluded flag, justification narrative, implementation status (designed / implemented / operating), and document reference. Version-control it from the first draft; auditors compare versions to check that exclusions are deliberate, not accidental.

What auditors flag most often:

• Controls marked "not applicable" for cloud security (5.23) or data masking (8.11) by organisations clearly using cloud platforms or handling personal data
• Implementation status listed as "planned" during Stage 2 — controls must be demonstrably operating, with evidence, not merely designed on paper
• A disconnect between the risk treatment plan and the SoA — if your risk register records a specific threat, the control treating that risk must appear as applicable in the SoA

ISO 27001 and the DPDP Act 2023: The Practical Overlap

The DPDP Act is fully operational in FY 2026-27. Section 8(5) requires every data fiduciary to implement reasonable security safeguards to prevent personal data breaches. The Act does not mandate ISO 27001 by name, but it creates a compliance obligation that ISO 27001 is structurally designed to fulfil.

Where the Controls Map Directly

CERT-In Incident Reporting

CERT-In's April 2022 directions require organisations to report cyber incidents within six hours of awareness to CERT-In, in the prescribed format. ISO 27001 controls 5.26 (Response to information security incidents) and 5.28 (Collection of evidence) directly support this obligation by requiring documented playbooks, defined response roles, and evidence preservation procedures. An organisation with a functioning ISMS incident management process is operationally positioned to meet the six-hour window; one without any documented process will struggle.

Cross-Border Processing and Enterprise Procurement

For Indian SaaS exporters, ISO 27001 certification satisfies much of GDPR Article 32's "appropriate technical and organisational measures" requirement for EU customers. US enterprise procurement teams routinely treat ISO 27001 as a vendor security baseline when a supplier does not yet hold SOC 2 Type II. In both cases, the certificate materially reduces the volume and length of customer-side security questionnaires, which can add six to twelve weeks to an enterprise sales cycle.

The Certification Roadmap: Six Phases for Indian Organisations

Phase 1 — Context, Scope, and Gap Assessment (Weeks 1–4)

Define the ISMS scope, identify all interested parties and their requirements, and conduct a structured gap assessment against all 93 Annex A controls. Output: a RAG-rated gap report and a project plan with resource assignments. Do not skip the context analysis — understanding your regulatory environment (DPDP, CERT-In, sector regulator) at this stage prevents late-stage discoveries.

Phase 2 — Risk Assessment and Risk Treatment (Weeks 4–10)

Build the information asset register, identify threats and vulnerabilities for each asset category, assign likelihood and impact ratings to derive a risk score, and select treatment options: treat (implement a control), tolerate (accept residual risk with sign-off), terminate (exit the activity), or transfer (cyber insurance or contractual allocation). The SoA is drafted by the end of this phase based on treatment decisions.

Phase 3 — Policy, Control Design, and Implementation (Weeks 8–20)

Write and obtain management approval for all ISMS policies. Implement the technical and operational controls selected in the SoA. For a software company, this phase typically includes deploying or configuring SIEM, DLP, patch management, MFA enforcement, and establishing a secure SDLC. This phase takes the longest and must run for a minimum of 90 days — ideally six months — before Stage 2 to generate audit evidence.

Phase 4 — Internal Audit and Management Review (Weeks 18–22)

Conduct a full internal audit against all clauses and applicable Annex A controls. Raise non-conformities, implement corrective actions, and hold the first formal management review to assess ISMS performance. Both the internal audit report and management review minutes are mandatory documents that auditors request at Stage 1.

Phase 5 — Stage 1 and Stage 2 Certification Audit

Stage 1 (documentation review, one to two days): The certification body auditor reviews the ISMS scope, SoA, risk assessment methodology, key policies, and internal audit report. Observations raised at Stage 1 must be resolved before Stage 2 is scheduled. Common Stage 1 findings: SoA exclusion justifications missing, internal audit scope too narrow, management review not yet held.

Stage 2 (on-site evidence audit, one to four days depending on headcount and scope): Auditors interview personnel at multiple levels, test controls against evidence, review system logs and access reports, check physical security, and sample supplier agreements. Major non-conformities must be closed with root-cause analysis and objective evidence within 90 days of the audit close date. The certificate is issued after the non-conformities are accepted by the lead auditor.

Choose a certification body accredited by NABCB (National Accreditation Board for Certification Bodies, under QCI) or by another IAF MLA signatory body. NABCB-accredited certificates are internationally recognised.

Phase 6 — Surveillance Audits and Recertification

Year 1 surveillance (approximately six to twelve months post-certification), Year 2 surveillance, and Year 3 recertification (full re-audit). Missing a surveillance audit without approved deferral results in certificate suspension and, ultimately, withdrawal.

Worked Example: Cost and Timeline for a Mid-Size Indian SaaS Company

Scenario: A 150-person B2B SaaS company headquartered in Pune, with an AWS Mumbai-hosted product, an 80-person development team, a 30-person customer success function, and 40 shared-services employees. ISMS scope: software development and cloud delivery services.

Target timeline: 7 months from project kick-off to Stage 2 completion.

Indicative cost breakdown (FY 2026-27 rates):

Why this investment is commercially rational in FY 2026-27:

Under Schedule I of the DPDP Act, failure to implement reasonable security safeguards under Section 8(5) can attract a penalty of up to Rs. 250 crore per instance. A single enforcement action following a breach at this company — even at a fraction of the maximum penalty — would dwarf the certification cost. Additionally, removing a lengthy security questionnaire process from the enterprise sales cycle (conservatively worth Rs. 8–12 lakh in sales team time per year for a company closing 15–20 enterprise deals annually) puts the certification ROI firmly in positive territory within Year 1.

Common Mistakes That Derail ISO 27001 Certifications

1. Under-Scoping to Reduce Audit Effort

Organisations exclude cloud infrastructure, offshore contractors, or subsidiary legal entities to keep the audit surface small. Auditors are specifically trained to examine interfaces with excluded entities. If your in-scope product runs on an out-of-scope AWS account managed by an out-of-scope DevOps team, expect a major non-conformity at Stage 2 covering supplier management and control of outsourced processes.

2. Treating Policies as Deliverables Rather Than Operating Controls

Writing an Access Control Policy, then failing to enforce quarterly access reviews or segregation of duties, is a non-conformity. The auditor pulls user access reports, checks when reviews were last conducted, and interviews IT administrators. Policy documents that do not reflect operational reality are actively harmful — they prove awareness without corresponding action.

3. Failing to Address Supplier Risk Management

Controls 5.19 through 5.22 cover supplier relationships. Most Indian IT companies process data on at least three cloud platforms and engage several third-party contractors. Each supplier touching the ISMS scope must be covered by a documented security assessment, a supplier information security agreement, and periodic monitoring. This is the most common source of major non-conformities at Stage 2.

4. Running the Risk Assessment as a Solo Desktop Exercise

A risk assessment completed in isolation by the CISO, without structured input from development leads, HR, legal, and finance, will not reflect actual operating threats. Auditors test this by asking business unit heads to describe the risks in their area during Stage 2. Discrepancies between the formal risk register and what operational staff say to the auditor create immediate credibility problems.

5. Leaving Evidence Generation Too Late

The SoA declares controls "implemented." The auditor at Stage 2 asks for six months of access review records, patch management completion logs, security awareness training attendance, DLP alert review records, and incident tickets. If the ISMS became operational four weeks before Stage 2, the evidence trail does not exist. Build your evidence log from Day 1 of implementation, not from when you book the Stage 2 audit.

6. Confusing the Certificate Scope with Full Legal Compliance

ISO 27001 certification applies to the defined ISMS scope — not to the entire legal entity. Activities, data categories, or business functions outside the scope boundary remain the company's own risk. Your legal and compliance teams must understand that the certificate is a scoped assurance, not a blanket DPDP or IT Act compliance declaration.

Key Takeaways

• ISO 27001:2022 is a management system standard, not a technical checklist. Certification requires board-level governance, a documented risk management process, and months of operational evidence — not just policies and software tools.
• The 2022 edition has 93 controls across four themes. If your certificate still references the 2013 standard (114 controls, 14 domains), it expired by 31 October 2025 and requires urgent recertification under the current version.
• The Statement of Applicability is your most important document. Every Annex A control must be assessed, inclusion or exclusion justified, and linked to an implementing document. Auditors review it before anything else.
• DPDP Act Section 8(5) and ISO 27001 are designed to work together. Controls 5.23 (cloud security), 8.10 (information deletion), 8.11 (data masking), and 5.24–5.26 (incident management) directly satisfy the DPDP's reasonable safeguards standard and support CERT-In's six-hour breach reporting requirement.
• First-year certification costs for an Indian mid-size company typically range from Rs. 13 lakh to Rs. 29 lakh. A single DPDP enforcement action for inadequate security safeguards can reach Rs. 250 crore — making the investment straightforward to justify.
• The most common cause of audit failure is missing evidence, not missing controls. Operate your ISMS for a minimum of three months — ideally six — before Stage 2, and log evidence from the first day of implementation.
• Scope discipline determines the value of the certificate. A well-defined, honestly bounded scope that includes your cloud infrastructure, your key suppliers, and your data-processing functions is more credible — and more defensible — than a narrow scope designed to minimise audit effort.