India's Most Trusted ISO/IEC 27001:2022 ISMS Certification Consultants — 93 Annex A Controls, Zero Major NCRs

ISO/IEC 27001:2022 is the internationally recognised standard for Information Security Management Systems (ISMS) — the third edition, published in October 2022. It is jointly published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), and is the successor to ISO/IEC 27001:2013.

The standard specifies requirements for establishing, implementing, maintaining, and continually improving an ISMS — a systematic approach to managing sensitive company information so that it remains confidential, integral, and available (the CIA triad). The ISMS framework covers:

• Confidentiality: Ensuring information is accessible only to those authorised to have access
• Integrity: Safeguarding the accuracy and completeness of information and processing methods
• Availability: Ensuring authorised users have access to information and associated assets when required

What ISO 27001:2022 requires (at clause level):

• Clause 4 — Context: Understand the organisation and its context (internal/external issues), identify interested parties and their IS requirements, define ISMS scope
• Clause 5 — Leadership: Top management commitment, IS policy, roles and responsibilities
• Clause 6 — Planning: Information security risk assessment, risk treatment plan, IS objectives
• Clause 7 — Support: Resources, competence, awareness, communication, documented information
• Clause 8 — Operation: Operational planning, risk assessment, risk treatment implementation
• Clause 9 — Performance Evaluation: Monitoring and measurement, internal audit, management review
• Clause 10 — Improvement: Nonconformity and corrective action, continual improvement
• Annex A: 93 controls across 4 themes — organisations select applicable controls based on risk assessment. All controls must be evaluated in the Statement of Applicability (SoA).

Key changes from ISO 27001:2013 to 2022:

• Annex A restructured from 114 controls / 14 domains → 93 controls / 4 themes
• 11 new controls added (threat intelligence, cloud security, ICT readiness, physical security monitoring, configuration management, data masking, data leakage prevention, monitoring activities, web filtering, secure coding, information deletion)
• 24 controls merged from the 2013 edition
• 58 controls revised with updated or clarified wording
• Clause text changes — minor updates aligned with latest Annex SL Harmonised Structure
• Transition deadline: October 2025 — all ISO 27001:2013 certificates must be upgraded to 2022 edition by then

What ISO 27001:2022 does NOT do: It does not specify a minimum level of information security performance, prescribe specific technology solutions, or guarantee an organisation is immune to cyberattacks. It establishes a management framework for systematic risk-based information security governance — the security baseline is determined by the organisation's own risk assessment.

ISO/IEC 27001:2022 introduced 11 new controls in Annex A that did not exist in the 2013 edition. These new controls reflect the evolution of the cybersecurity threat landscape — particularly cloud adoption, supply chain attacks, and data leakage risks. Every organisation implementing or transitioning to ISO 27001:2022 must evaluate all 11 in their Statement of Applicability.

1. A.5.7 — Threat Intelligence (Organisational)

Organisations must collect, analyse, and produce threat intelligence relating to information security threats. This includes: subscribing to threat intelligence feeds (CERT-In alerts, ISAC feeds, commercial threat intel), integrating threat intelligence into vulnerability management and incident response processes, and producing or consuming sector-specific threat intelligence. For Indian organisations, CERT-In's alerts and advisories satisfy part of this requirement. Automation through a SIEM/SOAR platform is common implementation.

2. A.5.23 — Information Security for Use of Cloud Services (Organisational)

A dedicated control for cloud security — establishing processes for acquisition, use, management, and exit from cloud services. Covers: cloud risk assessment before adoption, cloud provider security assessment, shared responsibility model documentation, cloud-specific access controls, data residency and sovereignty requirements (critical for Indian organisations — DPDPA 2023 and RBI data localisation requirements), encryption of data in cloud, and cloud exit procedures.

3. A.5.30 — ICT Readiness for Business Continuity (Organisational)

ICT readiness planning and implementation to support business continuity objectives. Covers: defining RTO and RPO for critical information systems, implementing backup and replication, testing recovery procedures, integrating ICT continuity into the broader Business Continuity Plan (BCP). Aligns with ISO 22301 for organisations pursuing combined ISMS + BCMS certification.

4. A.7.4 — Physical Security Monitoring (Physical)

Continuous monitoring of premises for unauthorised physical access. This encompasses: CCTV systems with coverage of server rooms, data centres, and secure areas; access control event logging and alert monitoring; guard presence where appropriate; physical intrusion detection systems. CCTV footage retention requirements and access log review frequency must be defined.

5. A.8.9 — Configuration Management (Technological)

Configurations of hardware, software, services, and networks must be established, documented, implemented, monitored, and reviewed. This is among the most operationally demanding new controls — requiring: defined security baselines for all system types (server, endpoint, network, cloud), automated compliance checking (SCCM, Ansible, CIS-CAT), configuration change management with authorisation, and detection and remediation of configuration drift.

6. A.8.10 — Information Deletion (Technological)

Information stored in information systems, devices, or other storage media must be deleted when no longer required. Addresses: data retention schedules, secure deletion procedures (data wiping standards — NIST 800-88, DoD 5220.22-M), deletion from cloud services and backup tapes, and deletion verification records. Critical for DPDPA 2023 compliance — the right to erasure creates a legal obligation that requires a functioning deletion process.

7. A.8.11 — Data Masking (Technological)

Data masking must be used in accordance with the organisation's access control policy and information handling requirements. Covers: masking of sensitive data in non-production environments (test, development, staging), dynamic data masking in applications to restrict sensitive data from unauthorised personnel, anonymisation and pseudonymisation as privacy-enhancing techniques aligned with DPDPA 2023 and GDPR obligations.

8. A.8.12 — Data Leakage Prevention (Technological)

Data leakage prevention (DLP) measures must be applied to systems, networks, and devices that process, store, or transmit sensitive information. Requires: DLP tool deployment (endpoint DLP, network DLP, email DLP, cloud DLP), data classification as the foundation for DLP policy, monitoring of data exfiltration channels (USB, email, cloud upload, printing), alert and response procedures for DLP incidents.

9. A.8.16 — Monitoring Activities (Technological)

Networks, systems, and applications must be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents. This is the operational SIEM/SOC requirement — log aggregation, normalisation, correlation rules, alerting, triage, and incident response. For Indian organisations, CERT-In's April 2022 directions mandate 6-hour incident reporting and extensive log retention — making SIEM/log management a regulatory as well as ISO 27001 requirement.

10. A.8.23 — Web Filtering (Technological)

Access to external websites must be managed to reduce exposure to malicious content. Web filtering should block: known malicious URLs and IP addresses, categories of inappropriate content, phishing sites and command-and-control (C2) infrastructure. Implementation: proxy/next-generation firewall web filtering, DNS filtering (e.g., Cisco Umbrella), browser-based filtering for remote workers, whitelist/blacklist management.

11. A.8.28 — Secure Coding (Technological)

Secure coding principles must be applied to software development. Covers: secure coding standards adoption (OWASP, CERT Secure Coding Standards), developer secure coding training, static application security testing (SAST), dynamic application security testing (DAST), code review procedures including security review, software composition analysis (SCA) for open-source vulnerabilities, and security requirements in the SDLC from design phase.

The Statement of Applicability (SoA) is the most important single document in an ISO 27001:2022 ISMS — and the document most scrutinised by certification body auditors in Stage-1. It is required by ISO 27001:2022 Clause 6.1.3(d) and must:

• List all 93 Annex A 2022 controls
• For each control: state whether it is applicable or not applicable
• For applicable controls: provide justification for inclusion (typically: risk treatment requirement, legal/regulatory requirement, contractual requirement, or business requirement)
• For not applicable controls: provide justification for exclusion (must demonstrate the exclusion does not affect the organisation's ability to achieve ISMS objectives and is not driven by avoiding an applicable risk)
• For applicable controls: describe the current implementation status (implemented, partially implemented, planned)

The SoA is not just a checklist — it is a governance document:

The SoA connects the risk assessment findings to the selected controls — demonstrating that control selection is risk-driven, not arbitrary. For every control selected, the link to the risk(s) it addresses should be traceable. For every risk in the risk register, the control(s) treating it should be traceable to the SoA. This bidirectional traceability is tested in Stage-1 and Stage-2.

What the SoA should contain for each control (best practice format):

• Control reference: A.5.1, A.5.2 … A.8.28
• Control title: As per ISO 27001:2022 Annex A
• Applicable? Yes/No
• Justification for inclusion/exclusion: e.g., "Risk R-047 (Unauthorised access to customer database) — control mitigates access privilege abuse" OR "Not applicable — organisation has no software development activity (A.8.25, A.8.26, A.8.27, A.8.28)"
• Implementation status: Fully Implemented / Partially Implemented / Planned (with target date) / Not Applicable
• Responsible owner: Role responsible for control implementation and maintenance
• Evidence reference: Link to the policy, procedure, system configuration, or record that evidences control implementation

Common SoA errors that cause Stage-1 non-conformities:

• Excluding controls without credible justification — e.g., excluding A.8.12 (Data Leakage Prevention) for a company processing large volumes of customer financial data, without explaining why DLP is not applicable
• All controls marked "applicable" without any exclusions — a sign that the SoA was not genuinely reviewed and the organisation has not thought about what is truly relevant to its context
• No traceability between risk register and SoA — the auditor cannot verify that control selection was risk-driven
• Implementation status not current — SoA shows controls as "implemented" but Stage-2 audit finds controls not functioning
• SoA not signed by senior management — the SoA requires management approval (Clause 6.1.3)

ISO 27001:2022 SoA vs ISO 27001:2013 SoA: If transitioning from 2013 to 2022, the existing SoA must be completely rebuilt to reference the 93 Annex A 2022 controls (not the 114 controls from 2013). The 24 merged controls and 11 new controls require fresh evaluation. The 58 revised controls require review to confirm the existing implementation still satisfies the revised control text. This is a significant revision effort — PrecisionTech provides a structured mapping tool that accelerates the SoA transition process.

ISO 27001:2022 Clause 6.1.2 requires that the organisation defines and applies an information security risk assessment process. The standard gives considerable flexibility in methodology — it does not prescribe a specific approach. However, the methodology must be: consistent, produce comparable and reproducible results, and consider the CIA impact of risks on information assets.

Two primary risk assessment methodologies used under ISO 27001:2022:

1. Asset-based risk assessment (traditional approach — used in ISO 27001:2013 era):

• Build a comprehensive asset inventory — information assets (databases, files, intellectual property, personal data), software assets, hardware assets, services, people, locations
• For each asset: identify applicable threats (malware, insider threat, natural disaster, human error) and vulnerabilities (unpatched software, weak passwords, lack of encryption)
• Assess the risk for each threat/vulnerability combination: Likelihood × CIA Impact = Risk Rating
• Record in risk register with asset owner and risk owner assigned
• Suitable for organisations with clearly defined, bounded information environments

2. Scenario-based risk assessment (modern approach — gaining adoption):

• Define information security risk scenarios — event-based descriptions: "Ransomware encrypts customer database," "Phishing attack compromises employee credentials," "Third-party cloud provider suffers data breach exposing customer PII"
• For each scenario: assess likelihood (based on threat intelligence, historical data, industry benchmarks) and impact (financial, operational, reputational, regulatory)
• Risk rating = Likelihood × Impact
• Map to relevant Annex A controls that mitigate each scenario
• Suitable for organisations with complex, dynamic, cloud-based environments where an exhaustive asset inventory is impractical

ISO 27001:2022 risk assessment process — step by step:

1. Define risk criteria: Risk acceptance threshold (e.g., risk scores above 12 on a 25-point matrix require treatment), risk appetite statement, risk assessment scoring scales (likelihood 1–5, impact 1–5)
2. Identify risks: Identify threats and vulnerabilities affecting in-scope information assets or scenarios
3. Analyse risks: Assess current controls already in place — residual risk after existing controls
4. Evaluate risks: Compare residual risk to risk acceptance threshold — classify as: Accept (below threshold, risk owner sign-off), Treat (select Annex A controls), Avoid (discontinue the risky activity), Share (transfer via insurance or contract)
5. Select controls: Map to Annex A 2022 controls for each "treat" decision
6. Document the risk register: Risk ID, description, asset/scenario, threat, vulnerability, inherent risk rating, existing controls, residual risk, treatment decision, treatment controls selected, risk owner, residual risk rating post-treatment, risk acceptance sign-off

Risk assessment review triggers:

• At planned intervals (typically annually for the full risk register)
• When significant organisational changes occur — new systems, new processes, new cloud services, new third-party relationships, acquisitions
• Following an information security incident — the incident reveals a risk not adequately assessed
• When significant changes occur in the threat landscape — new threat intelligence, new vulnerability disclosures (zero-days)

PrecisionTech uses a structured risk assessment workbook that integrates with the SoA — enabling bidirectional traceability from risk to control to SoA and from SoA to control to risk. The risk register is maintained as a living document updated by risk owners with PrecisionTech's annual maintenance support.

ISO/IEC 27001:2022 was published in October 2022, replacing ISO/IEC 27001:2013. The International Accreditation Forum (IAF) granted a 36-month transition period — meaning all organisations must transition to the 2022 edition by October 31, 2025. After that date, ISO 27001:2013 certificates are no longer valid.

Key differences — ISO 27001:2013 vs ISO 27001:2022:

Annex A restructuring (most significant change):

• 2013: 114 controls in 14 control domains (A.5 through A.18)
• 2022: 93 controls in 4 themes (Organisational, People, Physical, Technological)
• 11 new controls, 24 merged controls, 58 revised controls, 0 controls deleted (all 2013 controls are present in the 2022 edition — either retained, merged, or enhanced)

New Annex A controls in 2022 (not present in 2013):

• A.5.7 Threat intelligence
• A.5.23 Information security for use of cloud services
• A.5.30 ICT readiness for business continuity
• A.7.4 Physical security monitoring
• A.8.9 Configuration management
• A.8.10 Information deletion
• A.8.11 Data masking
• A.8.12 Data leakage prevention
• A.8.16 Monitoring activities
• A.8.23 Web filtering
• A.8.28 Secure coding

Clause-level changes (Clauses 4–10):

• Clause 6.2: Information security objectives must now also be "monitored" (new word added)
• Clause 6.3: New clause — Planning of changes. When the organisation determines the need for changes to the ISMS, changes must be carried out in a planned manner. (Addresses management of change within the ISMS itself.)
• Clause 8.1: Reference to "planned changes" and "unintended changes" — management of change formalized
• Clause 9.1: Monitoring, measurement, analysis and evaluation — strengthened requirement for documentation

Transition process for ISO 27001:2013 certified organisations:

• Step 1 — Conduct 2013 vs 2022 gap assessment: Compare your existing SoA against the 2022 Annex A to identify which new controls are applicable and which merged controls need re-evaluation
• Step 2 — Update the SoA: Rebuild the SoA against the 93 Annex A 2022 controls — evaluating all 11 new controls for applicability and updating justifications for all 24 merged and 58 revised controls
• Step 3 — Implement missing controls: Implement applicable new controls from Annex A 2022 — particularly A.5.7 (threat intelligence), A.5.23 (cloud security), A.8.9 (configuration management), A.8.12 (DLP), A.8.16 (SIEM monitoring)
• Step 4 — Update documentation: Update the IS policy suite to reference 2022 edition, update risk assessment process to align with 2022 clause requirements, update internal audit checklist
• Step 5 — Internal audit and management review under 2022: Conduct an internal audit using the 2022 clause checklist and updated SoA before the transition surveillance or recertification audit
• Step 6 — Transition audit with CB: Request a transition audit (may be combined with the next scheduled surveillance audit if timing allows) — CB verifies 2022 edition conformance, issues new certificate referencing ISO/IEC 27001:2022

Organisations that have not yet been certified: Should certify directly to ISO/IEC 27001:2022 — no need to ever implement the 2013 edition.

PrecisionTech provides both the transition gap assessment tool (mapping 2013 controls to 2022 equivalents) and end-to-end transition implementation — including the SoA rebuild, new control implementation, and CB transition audit support.

For Indian organisations, ISO 27001:2022 is not just an international certification — it directly supports compliance with India's rapidly evolving information security and data protection regulatory framework. Two of the most significant Indian regulatory requirements — CERT-In's April 2022 Directions and the Digital Personal Data Protection Act 2023 (DPDPA) — have strong alignment with ISO 27001:2022 controls.

CERT-In Directions, April 2022 — Alignment with ISO 27001:2022:

CERT-In (Indian Computer Emergency Response Team) issued mandatory cybersecurity directions in April 2022 applicable to all service providers, intermediaries, data centres, body corporates, and government organisations in India. Key requirements and ISO 27001:2022 control alignment:

• 6-hour cybersecurity incident reporting: CERT-In requires mandatory reporting of 20 categories of cybersecurity incidents within 6 hours of detection. ISO 27001:2022 A.5.24 (Information security incident management planning and preparation) and A.5.26 (Response to information security incidents) provide the ISMS framework for detecting, assessing, and reporting incidents within this timeline. A functioning SIEM (A.8.16 — Monitoring activities) is essential for achieving 6-hour detection-to-reporting.
• Log retention — 180 days: CERT-In requires ICT system logs to be retained for 180 days within India. ISO 27001:2022 A.8.15 (Logging) and A.8.16 (Monitoring activities) address log management. ISO 27001 organisations must ensure log retention policies specifically address the 180-day minimum.
• System clock synchronisation (NTP): CERT-In requires all systems to synchronise clocks with NTP servers of National Informatics Centre (NIC) or National Physical Laboratory (NPL). ISO 27001:2022 A.8.17 (Clock synchronisation) directly addresses this requirement.
• Virtual asset service providers: Cryptocurrency and virtual asset service providers face enhanced CERT-In requirements including mandatory KYC and transaction record maintenance. ISO 27001:2022 provides the information security governance framework for satisfying these requirements.
• Designated point of contact: CERT-In requires a designated point of contact for CERT-In interaction. This aligns with ISO 27001:2022 A.5.5 (Contact with authorities) and A.5.24 (Incident management planning).

Digital Personal Data Protection Act 2023 (DPDPA) — Alignment with ISO 27001:2022:

DPDPA 2023 is India's comprehensive data protection law — applicable to all Data Fiduciaries (organisations processing digital personal data of Indian citizens). ISO 27001:2022 provides significant alignment:

• Appropriate security safeguards (Section 8(5)): DPDPA requires Data Fiduciaries to implement appropriate technical and organisational measures to ensure security of personal data. ISO 27001:2022 certification is the internationally recognised evidence of such measures — an organisation with ISO 27001 certification demonstrates systematic security governance satisfying Section 8(5).
• Data breach notification within 72 hours (anticipated in DPDPA rules): DPDPA requires notification to the Data Protection Board and affected Data Principals following a personal data breach. ISO 27001:2022 incident management controls (A.5.24–A.5.28) provide the framework for detecting, assessing, and notifying within this timeframe.
• Right to erasure / data deletion (Section 12): DPDPA grants Data Principals the right to erasure of their personal data. ISO 27001:2022 A.8.10 (Information deletion) — one of the 11 new 2022 controls — directly addresses secure, verified deletion of data. ISO 27001:2022 organisations must build data deletion procedures aligned with DPDPA Section 12.
• Data masking and pseudonymisation: DPDPA compliance may require data masking in non-production environments and anonymisation/pseudonymisation as privacy-preserving measures. ISO 27001:2022 A.8.11 (Data masking) directly addresses this.
• Third-party/Data Processor management: DPDPA Section 8(2) requires Data Fiduciaries to enter into contracts with Data Processors imposing equivalent security obligations. ISO 27001:2022 A.5.19–A.5.22 (supplier security controls) provide the framework for third-party data processor due diligence, security contract requirements, and ongoing monitoring.
• Significant Data Fiduciaries (SDF): Organisations designated as Significant Data Fiduciaries face enhanced obligations including Data Protection Impact Assessments (DPIA) and appointment of a Data Protection Officer (DPO). ISO 27001:2022 A.5.35 (Independent review of information security) and ISO 27701:2019 (Privacy Information Management System — extension to ISO 27001) provide the governance framework for these enhanced obligations.

Other Indian regulatory alignments:

• RBI IT Framework for Banks (2011, updated): ISO 27001 certification is recommended by RBI for banks and NBFCs as evidence of IT risk governance. A.8.16 (Monitoring), A.8.15 (Logging), supplier controls, and BCP align with RBI requirements.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF, 2024): SEBI requires Market Infrastructure Institutions (MIIs) and Qualified Regulated Entities to implement cybersecurity frameworks — ISO 27001:2022 certification is explicitly referenced as evidence of compliance for the Foundational framework tier.
• IRDAI Cybersecurity Framework: Insurance Regulatory and Development Authority of India guidelines for insurers — ISO 27001 certification provides the underlying ISMS framework for IRDAI cybersecurity compliance.

PrecisionTech builds CERT-In and DPDPA 2023 compliance mapping directly into the ISMS implementation — ensuring that ISO 27001:2022 certification simultaneously advances regulatory compliance, not just international certification.

Supplier and third-party security is one of the most operationally demanding areas of ISO 27001:2022 — and one of the highest-risk areas for most organisations. Supply chain attacks (SolarWinds, Log4Shell, MOVEit, etc.) have demonstrated that attackers routinely compromise organisations through their suppliers rather than through direct attack. ISO 27001:2022 Annex A provides a comprehensive supplier security control set (A.5.19–A.5.23).

ISO 27001:2022 Supplier Security Controls:

A.5.19 — Information Security in Supplier Relationships:

A supplier security policy must be established covering: identification and classification of suppliers by access level and data sensitivity (Tier 1 — access to critical systems/data, Tier 2 — access to internal systems, Tier 3 — no direct access but provide business-critical services), information security requirements for supplier agreements, supplier risk assessment process, monitoring and review of supplier security performance.

A.5.20 — Addressing Information Security Within Supplier Agreements:

All supplier agreements where the supplier accesses, processes, stores, or transmits organisational information or provides ICT services must include security clauses: data protection obligations, incident notification requirements (72-hour notification to align with DPDPA and CERT-In requirements), right-to-audit, security control requirements, sub-processing restrictions, data return/deletion on termination, regulatory compliance obligations (CERT-In, DPDPA). Many Indian organisations discover their existing vendor contracts have no security clauses — remediation requires legal support and vendor negotiation.

A.5.21 — Managing Information Security in the ICT Supply Chain:

Security requirements must be defined for ICT products and services acquired through the supply chain — covering: hardware supply chain integrity (authentic, unmodified components), software supply chain security (Software Bill of Materials, open-source component tracking with SCA tools), managed service provider security controls, and hardware/software security configuration verification before deployment.

A.5.22 — Monitoring, Review and Change Management of Supplier Services:

Supplier security performance must be monitored and reviewed — through: annual security questionnaires, third-party penetration test results review, security incident reports from suppliers, audit rights exercise (or SOC 2 Type II reports in lieu of right-to-audit), and change notification management (suppliers must notify of significant changes to their security environment).

A.5.23 — Information Security for Use of Cloud Services (NEW in 2022):

Cloud service security is specifically addressed as a dedicated new 2022 control — recognising that most organisations' primary "supplier" risk is now with cloud service providers (AWS, Azure, GCP, SaaS vendors). Requirements: cloud provider risk assessment before adoption, shared responsibility model documentation (what the CSP secures vs. what the organisation is responsible for), cloud-specific access controls (IAM, privileged access, MFA enforcement), data residency and sovereignty requirements (critical for Indian organisations — DPDPA and RBI data localisation), encryption of data in transit and at rest in cloud, cloud exit procedures (data portability, deletion certification).

Building a supplier security programme for ISO 27001:2022:

• Supplier inventory: Complete register of all suppliers and third parties with access to information assets — categorised by tier/risk level
• Supplier security assessment: Questionnaire-based (for lower-tier suppliers) and evidence-based review (SOC 2 Type II, ISO 27001 certificate, penetration test report — for higher-tier suppliers)
• Security contract clauses: Standard security addendum for all supplier agreements — updated with DPDPA 2023 data processor obligations
• Cloud provider assessment: Structured review of AWS/Azure/GCP shared responsibility model, IAM configuration, data residency, encryption, and exit procedure
• Ongoing monitoring: Annual security review cycle, supplier incident notification protocol, change management notifications

PrecisionTech provides a complete supplier security programme — supplier inventory template, tiered security questionnaire, security contract clause library (including DPDPA-compliant data processor agreements), and cloud provider assessment checklist for AWS, Azure, and GCP.

ISO 27001:2022 and SOC 2 Type II are both widely recognised information security assurance frameworks — but they have different origins, scopes, and market applicability. Indian IT, ITES, and software product companies frequently face the question of which to pursue — or whether to pursue both.

ISO 27001:2022:

• Origin: ISO/IEC — internationally recognised globally
• Applicable to: Any organisation globally — not US-specific
• Standard type: Management system certification — certifies that the ISMS meets the standard's requirements
• Certification basis: Third-party audit by NABCB-accredited certification body — certificate issued for 3 years with annual surveillance audits
• Control framework: 93 controls in 4 themes (Annex A 2022) — selected based on organisation's risk assessment
• Scope: Covers physical security, HR security, supplier management, business continuity, legal compliance, and technology — very broad
• Indian relevance: Required by Indian government agencies, PSUs, BFSI clients, healthcare clients, and export clients in EMEA, APAC, and Indian regulatory frameworks (CERT-In, SEBI CSCRF). CERT-In references ISO 27001 in its guidelines.
• Cost in India: Implementation consulting INR 40,000–5,00,000 + CB audit fees INR 80,000–4,00,000 (3-year cycle)

SOC 2 Type II:

• Origin: AICPA — primarily US-market recognition
• Applicable to: Service organisations processing customer data — strongest in North American market
• Standard type: Attestation report — CPA firm attestation that controls operated effectively over a period (typically 12 months)
• Certification basis: CPA firm audit — produces a SOC 2 Type II report (not a certificate); report must be renewed annually
• Control framework: Trust Services Criteria (TSC) — Security, Availability, Processing Integrity, Confidentiality, Privacy (organisation selects applicable criteria)
• Scope: Primarily technology and operational controls — less coverage of physical security, HR, and supply chain than ISO 27001
• Indian relevance: Required primarily by US-based clients (banks, healthcare, SaaS buyers in the USA). UK/European/APAC/Indian clients typically prefer ISO 27001. Many large Indian IT companies maintain both.
• Cost in India: Readiness consulting INR 60,000–6,00,000 + CPA firm audit (must be a US-registered CPA firm with AICPA attestation standards) USD 15,000–60,000

Key differences in practice:

• Coverage: ISO 27001 has broader scope (physical, HR, supplier, BCP). SOC 2 has deeper focus on operational security controls and their actual effectiveness over time.
• Continuous evidence: SOC 2 Type II tests controls over a 12-month period — demonstrating sustained effectiveness. ISO 27001 tests at a point in time with annual surveillance.
• Market recognition: ISO 27001 — global. SOC 2 — primarily US market. Both are increasingly cross-recognised.
• ISMS vs. Attestation: ISO 27001 certifies the management system. SOC 2 attests to control effectiveness. These are complementary perspectives.

Recommendation for Indian IT companies:

• Primarily serving Indian or EMEA/APAC clients: Prioritise ISO 27001:2022 — universally required, regulatory aligned, broader scope
• Primarily serving US clients: SOC 2 Type II is often the primary requirement — pursue it first, then consider ISO 27001 for additional market access
• Serving both US and global markets: Both — ISO 27001:2022 as the ISMS foundation, SOC 2 Type II as the operational attestation report for US clients. Many organisations find that implementing ISO 27001 first significantly reduces SOC 2 readiness effort (shared controls, shared documentation).

PrecisionTech implements ISO 27001:2022 ISMS with SOC 2 readiness built in — identifying shared controls, shared documentation, and shared evidence — minimising the incremental effort of pursuing both frameworks.

ISO 27001:2022 is as applicable — and often more relevant — to cloud-native and SaaS companies than to traditional on-premises IT organisations. Cloud-native organisations are frequently surprised by two realities: (1) the shared responsibility model means significant security responsibilities remain with the organisation even when using major cloud providers, and (2) ISO 27001:2022 Annex A has specific cloud controls (A.5.23 — new in 2022) that require structured cloud security governance.

How cloud changes the ISMS scope and control application:

Asset inventory in cloud environments:

• Traditional asset inventory (servers, routers, storage devices) is replaced or supplemented by cloud resource inventory: compute instances (EC2, VMs, Cloud Run), managed databases (RDS, Cloud SQL, Cosmos DB), object storage (S3, GCS, Azure Blob), serverless functions (Lambda, Cloud Functions, Azure Functions), container registries, API gateways, CDN configurations
• Cloud inventory must be maintained dynamically — automated discovery using cloud-native tools (AWS Config, Azure Resource Manager, GCP Asset Inventory) or third-party CSPM (Cloud Security Posture Management) tools (Prisma Cloud, Wiz, Lacework)

Access control in cloud (IAM governance):

• Cloud IAM policies, roles, and permission boundaries replace (or supplement) traditional Active Directory / LDAP access control
• Least privilege principle (A.5.15 — Access control) must be implemented for cloud IAM — no accounts with admin/full-access permissions as default
• Multi-factor authentication (A.8.5 — Secure authentication) mandatory for all cloud console access, especially for privileged roles
• Privileged access workstations (PAWs) or jump servers for cloud administration access
• Regular access reviews — quarterly review of cloud IAM roles and permissions (A.5.18 — Access rights)

Shared responsibility model — what the organisation remains responsible for:

• IaaS (AWS EC2, Azure VM, GCP Compute): Organisation responsible for: OS patching, OS configuration security, data encryption, IAM configuration, network security groups/firewall rules, application security, data backup configuration
• PaaS (AWS RDS, Azure App Service, GCP Cloud SQL): Organisation responsible for: IAM, data encryption configuration, data backup configuration, application code security, network access controls
• SaaS (Office 365, Salesforce, GitHub, Slack): Organisation responsible for: user provisioning and deprovisioning, MFA enforcement for users, data classification and handling in the SaaS platform, configuration of security features (conditional access, DLP policies in the SaaS tool)

Key cloud security controls under ISO 27001:2022 Annex A:

• A.5.23 — Cloud Services (new 2022): Cloud provider risk assessment, shared responsibility model documentation, cloud exit procedures, cloud data residency
• A.8.9 — Configuration Management (new 2022): Automated security baseline compliance (CIS Benchmarks for AWS, Azure, GCP) using CSPM tools
• A.8.12 — Data Leakage Prevention (new 2022): Cloud DLP (AWS Macie, Azure Purview, GCP DLP API) for sensitive data discovery and monitoring in cloud storage
• A.8.16 — Monitoring Activities (new 2022): Cloud SIEM integration — AWS CloudTrail + CloudWatch, Azure Monitor + Sentinel, GCP Cloud Logging + Chronicle — centralised security event monitoring
• A.8.20 — Networks Security: VPC design, security groups, NACLs, network segmentation in cloud
• A.8.24 — Use of Cryptography: Encryption at rest (AWS KMS/SSE, Azure Key Vault, GCP CMEK), TLS 1.2+ in transit

DevSecOps and ISO 27001:2022 in SaaS companies:

• A.8.25–A.8.28 cover the SDLC security controls — SAST, DAST, SCA, secure coding, security testing. Cloud-native SaaS companies with CI/CD pipelines must integrate security testing into the pipeline — not treat it as a separate review step
• A.8.28 (Secure Coding — new 2022) requires formal secure coding standards adoption and developer training — OWASP, SANS, or equivalent
• Infrastructure as Code (IaC) security scanning (e.g., tfsec for Terraform, Checkov) addresses configuration management (A.8.9) and secure development (A.8.25) simultaneously

PrecisionTech has specific cloud ISMS expertise — AWS, Azure, and GCP security architecture assessment, cloud IAM governance, CSPM tool integration, and CI/CD security pipeline design for SaaS companies pursuing ISO 27001:2022.

ISO/IEC 27701:2019 is the international standard for Privacy Information Management Systems (PIMS) — a privacy extension to ISO 27001. It provides additional requirements and guidance for establishing, implementing, maintaining, and continually improving a PIMS as an extension of an ISO 27001-certified ISMS.

What ISO 27701:2019 adds to ISO 27001:

• PII Controller requirements: Organisations that determine the purpose and means of processing personal data (equivalent to DPDPA Data Fiduciaries and GDPR Data Controllers) must implement additional privacy controls covering: lawful basis for processing, consent management, data subject rights handling (access, correction, erasure, portability), privacy impact assessment, privacy by design, transparency and notice
• PII Processor requirements: Organisations that process personal data on behalf of others (equivalent to DPDPA Data Processors and GDPR Data Processors) must implement controls covering: processing only per instructions, informing Controllers of sub-processing, returning/deleting data at termination, supporting Controller in responding to data subject rights requests
• Extended Annex A privacy controls: ISO 27701 extends the Annex A controls with privacy-specific additions — covering PII collection limitation, PII minimisation, accuracy of PII, retention limits, and privacy preservation in development

ISO 27701:2019 and DPDPA 2023 alignment for Indian organisations:

• ISO 27701 was designed with GDPR alignment but its principles directly map to DPDPA 2023 requirements
• Data Fiduciaries under DPDPA who implement ISO 27701:2019 as an extension of ISO 27001:2022 can demonstrate comprehensive privacy governance to the Data Protection Board of India
• The ISO 27701 controller controls map to: DPDPA notice requirements (Section 5), consent management (Section 6), data principal rights (Sections 11–14), accountability (Section 8)
• The ISO 27701 processor controls map to: DPDPA Data Processor obligations (Section 8(3)), data processor contract requirements

Who should consider ISO 27701:2019 alongside ISO 27001:2022:

• SaaS companies processing personal data of customers — healthcare data, financial data, consumer data
• BPOs and KPOs processing personal data on behalf of their clients
• E-commerce companies processing consumer personal data at scale
• Healthcare technology companies processing patient data
• HR technology companies processing employee data
• Any organisation seeking to demonstrate Significant Data Fiduciary readiness under DPDPA
• Organisations serving GDPR-regulated customers (EU clients, UK clients) or operating in GDPR jurisdictions

Practical implementation approach:

• ISO 27701:2019 cannot be certified standalone — it requires an existing ISO 27001 ISMS certification as the foundation
• Additional implementation effort for ISO 27701 over ISO 27001: typically 6–10 additional weeks for a medium-sized organisation
• Combined ISO 27001:2022 + ISO 27701:2019 certification is performed in a combined Stage-2 audit by the certification body
• The combined certificate references both standards and is renewed annually through combined surveillance audits

PrecisionTech designs DPDPA-aligned ISO 27701 implementations that serve as both international privacy certification and Indian regulatory compliance evidence — integrating consent management architecture, data subject rights procedures, and Data Protection Officer (DPO) governance into the ISMS extension.

Access control is one of the most foundational and consistently tested areas of ISO 27001:2022. It spans multiple Annex A controls across both Organisational and Technological themes — and is tested in Stage-2 through technical evidence review, configuration screenshots, and employee interviews.

Access control controls in ISO 27001:2022 Annex A:

• A.5.15 — Access Control: Access control policy — defining principles: least privilege, need-to-know, segregation of duties, role-based access control (RBAC)
• A.5.16 — Identity Management: Complete lifecycle management — provisioning, modification, deprovisioning. Formal onboarding/offboarding process. Timely account deactivation on termination (critical — ex-employee accounts left active are a top ISO 27001 finding)
• A.5.17 — Authentication Information: Management of secret authentication information (passwords, tokens, certificates) — password policy, multi-factor authentication, prohibition of shared accounts, prohibition of credential sharing
• A.5.18 — Access Rights: Formal access request and approval process. Periodic access reviews (user access reviews — at least annually, quarterly for privileged accounts). Access rights revocation on role change or termination.
• A.8.2 — Privileged Access Rights: Privileged accounts (domain admin, DBA, root, cloud admin) require: formal justification and approval, just-in-time (JIT) access where feasible, enhanced monitoring, separate account from standard user account, Privileged Access Management (PAM) tool for large organisations
• A.8.3 — Information Access Restriction: Application-level access control — what information/functions each user role can access within applications. RBAC in business applications (ERP, CRM, HRMS). Database access controls.
• A.8.5 — Secure Authentication: Multi-factor authentication (MFA) for all remote access, cloud console access, privileged accounts, and sensitive systems. FIDO2/WebAuthn, TOTP, hardware tokens, or SMS OTP (with risk acknowledgement for SMS OTP). Single Sign-On (SSO) integration.

Common access control non-conformities in ISO 27001:2022 audits:

• No formal user access request and approval process — access granted informally by email or verbal request without documented approval
• No periodic access review records — access rights accumulate over time (access creep) without periodic cleanup
• Shared accounts used for multiple people — cannot audit individual actions, violates A.5.16
• Terminated employees' accounts not promptly deactivated — the most common and most serious access control finding. Formal offboarding process with IT checklist and HR sign-off required.
• Default passwords unchanged on new systems — violates A.5.17
• Admin/privileged accounts used for routine work — violates A.8.2
• MFA not enforced for remote access (VPN, RDP, cloud console) — high severity finding, especially post-pandemic with widespread remote working
• Access rights not revoked when employees change roles — access rights from previous role retained alongside new role rights (access accumulation)

Building a compliant access control programme:

• Access control policy — approved by management, reviewed annually
• Role-based access matrix — for all critical systems, define which roles have which access levels
• Onboarding checklist — standard access provisioned based on role; non-standard requires approval
• Offboarding checklist — mandatory IT sign-off, account disabled within 24 hours of termination, email forwarding limits (not indefinite), hardware return
• Privileged account register — all privileged accounts listed, owners assigned, quarterly review conducted
• User access review — quarterly for privileged accounts, annual for all accounts — reviewed by system owner, not IT
• MFA enforced — VPN gateway, cloud consoles, remote desktop, critical business applications
• PAM tool for large organisations — CyberArk, BeyondTrust, Delinea for privileged session management and credential vaulting

Information security incident management is covered by a cluster of controls in ISO 27001:2022 Annex A (A.5.24–A.5.28) and must be implemented as an integrated process covering detection, reporting, assessment, response, recovery, and post-incident review. For Indian organisations, CERT-In's 6-hour reporting mandate adds urgency to the detection-to-response timeline.

ISO 27001:2022 Incident Management Controls:

• A.5.24 — Information Security Incident Management Planning and Preparation: Define roles and responsibilities for incident management. Establish an Incident Response Team (IRT) or designate an incident coordinator. Define incident categories and severity levels. Prepare incident response playbooks for common scenarios (ransomware, DDoS, data breach, phishing compromise, insider threat). Integrate with CERT-In reporting obligations. Establish communication procedures — internal escalation, external notification (CERT-In, law enforcement, affected parties, media).
• A.5.25 — Assessment and Decision on Information Security Events: All potential security events must be assessed to determine if they constitute an information security incident. A defined triage process — classification criteria, severity matrix, escalation triggers. Initial assessment performed by first-responder (SOC analyst or designated IT person) within a defined timeframe (aligning with CERT-In 6-hour notification requirement requires detection within 2–3 hours of occurrence).
• A.5.26 — Response to Information Security Incidents: Incident response procedures covering: containment (isolating affected systems), eradication (removing malware, patching vulnerability), recovery (restoring from clean backup), evidence preservation (forensic chain of custody for legal/regulatory purposes), and customer/partner/regulatory notification timelines.
• A.5.27 — Learning from Information Security Incidents: Post-incident review (PIR) / lessons learned process. Root cause analysis. ISMS improvement actions — HIRA update, SoA review, policy/procedure update, training update. Metrics tracking — MTTD (Mean Time to Detect), MTTR (Mean Time to Respond), incident frequency by category.
• A.5.28 — Collection of Evidence: Evidence collection and preservation procedures for legal, regulatory, or forensic purposes. Forensic image of affected systems. Log preservation. Chain of custody documentation. Required if incident may involve law enforcement (FIR) or regulatory investigation (CERT-In, Data Protection Board).

CERT-In 6-hour notification — building a timeline-compliant incident response process:

• Hour 0 — Detection: SIEM alert, security tool alert, user report, or external notification (e.g., CERT-In alert that organisation is observed in threat intelligence)
• Hour 0–1 — Initial triage: First-responder assesses event, classifies as incident or false positive, escalates to incident coordinator if confirmed
• Hour 1–3 — Incident assessment: Incident coordinator determines scope, affected systems, data types involved, CERT-In reportable category
• Hour 3–6 — Notification preparation and submission: CERT-In incident report submitted at incidents@cert-in.org.in within 6 hours of detection/discovery. Report format per CERT-In direction guidance.
• Hour 6+ — Containment and investigation: Isolation, forensic imaging, eradication, recovery, post-incident review

Technical incident detection infrastructure aligned with ISO 27001:2022 A.8.16:

• SIEM platform (Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM, or equivalent) aggregating logs from: endpoints (EDR/AV), network devices (firewall, IDS/IPS), servers, applications, cloud services
• Correlation rules detecting: brute force attempts, lateral movement, data exfiltration patterns, privilege escalation, known malware IOCs, anomalous login times/locations
• 24×7 SOC coverage (internal or outsourced MSSP) for continuous alert triage — essential for meeting CERT-In 6-hour notification requirement round the clock
• EDR (Endpoint Detection and Response) on all endpoints — Microsoft Defender for Endpoint, CrowdStrike, SentinelOne

ISO 27001:2022 Clause 7.2 (Competence), Clause 7.3 (Awareness), and Annex A.6.3 (Information security awareness, education and training) together create a comprehensive mandatory framework for IS awareness and training. This is consistently one of the most tested areas in Stage-2 audits — evidence of actual training delivery and completion is required, not just training materials.

What ISO 27001:2022 requires:

Clause 7.2 — Competence: Identify the IS competence required for roles with ISMS responsibilities — IS manager, IT security team, developers, system administrators, auditors. Verify that persons in these roles have acquired the necessary competence through education, training, or experience. Take action to acquire required competence where gaps exist. Maintain documented records of competence (training certificates, education qualifications).

Clause 7.3 — Awareness: All persons doing work under the organisation's control (including contractors and third-party personnel with access to organisational systems) must be aware of: the IS policy, their contribution to ISMS effectiveness, the implications of not conforming with ISMS requirements (consequences of security breaches, disciplinary process).

A.6.3 — Information Security Awareness, Education and Training: Personnel and relevant interested parties must receive appropriate IS awareness education and training and regular updates of organisational policies and procedures relevant to their job function. Training must be: role-relevant (not one-size-fits-all), current (reflecting the current threat landscape and current organisational policies), evidenced (completion records maintained), and effective (periodic assessment of awareness effectiveness).

Mandatory training programme components for ISO 27001:2022:

General IS Awareness (all employees, contractors with system access):

• IS policy overview — what it covers, what employees must do
• Acceptable use of information assets (computers, internet, email, mobile devices)
• Password policy and multi-factor authentication
• Phishing and social engineering recognition — examples, red flags, what to do if targeted
• Data classification — what data is confidential, how to handle it
• Clear desk and clear screen policy
• Incident reporting — how and where to report a suspected security incident
• BYOD policy (if applicable)
• Remote working security — VPN usage, secure Wi-Fi, home working rules
• Frequency: At induction (before system access is granted) + annual refresh

Role-specific training:

• IT administrators/system administrators: Patch management, hardening procedures, privileged access management, log monitoring, change management, backup verification
• Software developers: OWASP Top 10, secure coding practices (A.8.28), input validation, SQL injection prevention, cross-site scripting prevention, dependency management and SCA
• Management/IS governance: Risk management principles, IS policy review and approval, management review inputs/outputs, third-party risk oversight
• Finance/HR (high phishing targets): Business email compromise (BEC) recognition, invoice fraud prevention, CEO fraud awareness, wire transfer verification procedures

Phishing simulation as IS awareness effectiveness measurement:

• Run simulated phishing campaigns (KnowBe4, Proofpoint Security Awareness Training, Cofense) — click rate before training is baseline, improvement over time demonstrates effectiveness
• Employees who click simulated phishing are automatically enrolled in targeted refresher training
• Phishing simulation results are documented as IS awareness effectiveness measurement for management review

Common IS awareness and training non-conformities in Stage-2 audits:

• No training completion records — training was conducted but not documented, or records cannot be produced for all employees
• New employees accessing systems before completing IS awareness training — particularly contractors and third-party staff
• Training not updated for current threats — training content from 3 years ago without any update for current phishing trends, ransomware, AI-generated deepfake threats
• Training not role-specific — developers receiving only general awareness training without OWASP/secure coding training
• No effectiveness measurement — awareness training delivered but never assessed for actual awareness improvement

ISO 27001:2022 Clause 9.2 requires planned internal audits at defined intervals to determine whether the ISMS conforms to the standard's requirements and the organisation's own ISMS requirements, and whether it is effectively implemented and maintained. The internal audit is the primary quality assurance mechanism between external certification body visits — and its quality directly predicts Stage-2 audit outcomes.

Internal audit programme planning (Clause 9.2.1):

• Annual audit programme: Define which ISMS clauses and Annex A controls will be audited in each audit cycle, with risk-based prioritisation — higher-risk controls and areas with previous non-conformities receive more frequent attention. All clauses and all applicable SoA controls must be covered over the audit cycle.
• Audit plan for each audit: Scope, objectives, audit criteria, audit methods, and audit team. Document and communicate to auditees in advance.
• Auditor competence and impartiality: Internal auditors must understand ISO 27001:2022 requirements and audit methodology. Auditors must not audit their own work — in small organisations, this may require cross-functional auditing or use of an external auditor for some areas.

Internal audit methodology for ISO 27001:2022:

Document review (what the ISMS claims to do):

• ISMS scope — does it reflect current organisational boundaries?
• SoA — is it current? Are implementation statuses accurate? Do justifications remain valid?
• Risk register — has it been updated for new systems, new threats, and post-incident learnings?
• Policy suite — are all policies current, reviewed within the defined review period, and approved by management?
• User access review records — have access reviews been completed for all critical systems within the required frequency?
• Training records — has all required IS awareness training been completed and documented for all employees?
• Incident log — have all incidents been recorded, investigated, and resolved?

Technical evidence review (what is actually implemented):

• Access control configuration screenshots — privileged account list, MFA enabled, terminated employee accounts deactivated
• Patch management records — vulnerability scan report, patch compliance rate, outstanding critical/high patches
• Backup test records — backup restoration test results
• Log retention verification — log retention settings confirming 180-day minimum (CERT-In)
• Antimalware status — console screenshot showing all endpoints protected and definitions current
• Encryption verification — TLS certificate configuration, storage encryption enabled
• Configuration baseline compliance — CSPM dashboard or CIS Benchmark scan results

Employee interviews (IS awareness testing):

• "If you received a suspicious email, what would you do?"
• "Where is the IS policy available? Have you read it?"
• "What does your clean desk policy require?"
• "When did you last attend IS awareness training?"
• "Have you ever reported a security concern? What happened?"

Internal audit report: Findings classified as conformities, observations (no non-conformity but potential risk), minor non-conformities (ISMS requirement not met but not systemic), major non-conformities (systemic failure or complete absence of a required control). CAPA (Corrective Action / Preventive Action) plan assigned for all non-conformities with responsible persons and target dates. Internal audit findings are a management review input (Clause 9.3).

Common fatal internal audit errors that cause Stage-2 failures:

• Internal audit conducted as document review only — no technical evidence review, no employee interviews. Stage-2 auditor tests implementation; if internal auditor did not, gaps will be found.
• All findings recorded as "conformities" — an internal audit with zero non-conformities is implausible for any ISMS with more than 50 employees. Auditors expect findings and CAPA records demonstrating continual improvement.
• CAPA not followed up — non-conformities from internal audit not closed before Stage-2. Open CAPAs are a Stage-2 finding.
• Audit not covering all applicable SoA controls — gap in audit coverage leaves untested areas that the CB auditor will find.

India's financial sector regulators — RBI, SEBI, and IRDAI — have developed sector-specific cybersecurity frameworks that have significant alignment with ISO 27001:2022. ISO 27001 certification does not automatically satisfy all regulatory requirements but provides the ISMS foundation that substantially reduces the gap and provides credible evidence of cybersecurity governance.

RBI — Reserve Bank of India:

• IT Framework for Banks (2011, RBI/2015-16/418): Covers IT governance, IS, IS risk management, IS assurance, cyber resilience. ISO 27001 certification is explicitly mentioned as an acceptable evidence of IS framework implementation for the IS assurance review.
• Cyber Security Framework for Banks (DBS.CO/CSITE.BC.11/33.01.001/2015-16): Requires banks to implement a Cyber Crisis Management Plan (CCMP), Security Operations Centre (SOC), cyber incident reporting to RBI within 2–6 hours (aligned with CERT-In 6-hour requirement). ISO 27001 Annex A controls for incident management (A.5.24–A.5.28) and monitoring (A.8.16) directly support these requirements.
• RBI Master Direction on IT (2023): Comprehensive updated IT governance framework for regulated entities — covers IS governance, IT risk, IT assurance, IS operations, outsourcing. ISO 27001:2022 ISMS implementation substantially addresses the IS governance, risk assessment, and IS operations requirements.
• RBI Data Localisation: RBI requires all payment system data to be stored only in India. ISO 27001:2022 A.5.23 (Cloud Services) and the asset management/data classification controls address data residency requirements — organisations must document where data resides and enforce cloud storage location requirements.

SEBI — Securities and Exchange Board of India:

• Cybersecurity and Cyber Resilience Framework (CSCRF), 2024: SEBI's comprehensive cybersecurity framework for Market Infrastructure Institutions (MIIs — stock exchanges, depositories, clearing corporations), Qualified Registered Entities (QREs), and other registered intermediaries. Entities are categorised into tiers with different compliance requirements. For Tier 1 entities (MIIs), ISO 27001:2022 certification is referenced as evidence of conformance with the "Foundational" cybersecurity controls.
• SEBI Circular on Cybersecurity Incidents: Requires reporting of material cybersecurity incidents to SEBI within 6 hours. ISO 27001 incident management controls provide the framework.
• System Audit: SEBI requires annual system audits for stock brokers and depository participants — ISO 27001 internal audit programme provides the underlying IS audit framework.

IRDAI — Insurance Regulatory and Development Authority of India:

• IRDAI Cybersecurity Framework (IRDAI/SDD/CIR/MISC/211/11/2021): Requires insurers to establish an IS governance framework, IS risk management, cybersecurity incident response, and data protection measures. ISO 27001:2022 ISMS directly satisfies the IS governance and risk management requirements of the IRDAI framework.
• Data Privacy and Protection in Insurance: Insurers process highly sensitive health and financial data — ISO 27001:2022 data classification (A.5.12), data handling (A.5.13), and supplier security (A.5.19–A.5.22) controls address insurer data protection obligations.

Practical recommendation for Indian BFSI organisations:

• Implement ISO 27001:2022 as the ISMS foundation — it provides the governance framework that all three regulators expect
• Add CERT-In compliance mapping to the ISMS — log retention, 6-hour incident notification, NTP synchronisation
• Add DPDPA 2023 controls to the ISMS (or ISO 27701:2019 extension)
• Map sector-specific regulatory requirements (RBI IT Direction, SEBI CSCRF, IRDAI framework) to the ISMS — maintaining evidence of regulatory compliance within the ISMS documentation system
• Annual regulatory compliance evidence reports can be produced from the ISMS — demonstrating to regulators that systematic IS governance is functioning

Understanding common non-conformities allows organisations to address them proactively — before Stage-1 or Stage-2 audits. The following are the most frequently identified NCRs in ISO 27001:2022 certification audits.

Stage-1 NCRs (documentation gaps):

• SoA incomplete or inconsistent (most frequent major NCR): Controls marked "Not applicable" without credible justification; no traceability between risk register and SoA; implementation status claimed as "Implemented" for controls that Stage-2 will show are not functioning; SoA references ISO 27001:2013 controls rather than 2022 Annex A; SoA not signed by management.
• Risk assessment methodology not documented: Organisation has a risk register but no documented methodology explaining how risks were identified, how the rating scales are defined, what the risk acceptance threshold is, and how controls were selected.
• Risk register not risk-assessed — a list of issues, not a risk assessment: Risk register contains a list of vulnerabilities or threats but without formal risk rating (Likelihood × Impact), risk acceptance threshold comparison, treatment decisions, or risk owner assignment.
• IS policy not meeting ISO 27001:2022 requirements (Clause 5.2): Policy not approved by top management, not communicated to all staff, too generic (no commitment to continual improvement, no mention of ISMS), or referencing 2013 edition.
• ISMS scope ambiguously defined: Scope statement does not clearly describe which locations, systems, processes, and organisational units are included and excluded, with justification for any exclusions.
• 11 new Annex A 2022 controls not evaluated in SoA: Common for organisations transitioning from ISO 27001:2013 — SoA has not been updated to include the 11 new controls.

Stage-2 NCRs (implementation gaps):

• Access control — terminated employee accounts not deactivated (most cited technical NCR): During account review, auditors identify accounts belonging to employees who have left the organisation that are still active. A formal, timely offboarding procedure is required with IT security verification within 24 hours of termination.
• Patch management — critical vulnerabilities unpatched beyond policy timeframe: Vulnerability scan report shows critical (CVSS 9.0+) or high (CVSS 7.0+) vulnerabilities on production systems that are beyond the organisation's defined remediation timeline (typically 7–30 days for critical). Patching process breakdown or exemption process not documented.
• No user access review evidence: Access control policy states quarterly privileged account review and annual general user access review — but no records of access reviews being conducted can be produced. This is systemic non-conformity with A.5.18.
• Supplier security — no security clauses in vendor contracts: Third-party suppliers with access to customer data or critical systems have contracts with no IS clauses — no incident notification requirement, no right-to-audit, no data protection obligations. Common for organisations that engaged suppliers before the ISMS was implemented.
• IS awareness training — incomplete records: Training was conducted but completion records are absent for some employees, especially contractors and third-party staff. Every person with access to in-scope systems must have a documented IS induction before access is granted.
• SIEM not covering all in-scope systems: The SoA states A.8.16 (Monitoring) is implemented but the SIEM does not collect logs from all critical systems — cloud services, SaaS applications, network devices, or a recently acquired/deployed system are not integrated.
• Backup not tested — or backup test records absent: Backup policy states monthly restoration tests — no records can be produced. Alternatively, backups exist but no restoration test has ever been performed.
• MFA not enforced for remote access: VPN or remote desktop access without MFA — particularly high-severity finding given the prevalence of credential stuffing attacks.
• Configuration management — no baseline defined: A.8.9 (new 2022 control) requires documented security configurations for systems. No baseline documents exist; no automated compliance checking in place.

ISO 27001:2022 certification timeline and cost are among the most frequently asked questions by organisations considering implementation. Here is a realistic guide for Indian organisations.

Factors affecting timeline:

• Current information security maturity: An IT company with existing security policies, SIEM, patch management, and access control processes takes significantly less time than a manufacturing company with minimal existing IS infrastructure
• ISMS scope complexity: A single-site SaaS company with 100 employees takes less time than a multi-site IT services company with 2,000 employees across 5 locations
• Cloud vs. on-premises environment: Cloud-native environments with automated controls (CSPM, IAM policies, encryption defaults) often achieve compliance faster than on-premises environments with manual controls
• Transition from ISO 27001:2013: Organisations already certified under 2013 edition can transition in 8–14 weeks (gap closure + transition audit) rather than full implementation timeline
• Regulatory requirements: Organisations with CERT-In SIEM/log retention requirements already implemented reduce the Technological controls implementation effort
• Resource availability: Organisations with a dedicated IS manager or IT security team implement faster than those where IS is a part-time role alongside other responsibilities

Realistic timelines for Indian organisations:

• Small startup / SaaS company (20–100 employees, single site, cloud-native): 10–16 weeks
• Medium IT/ITES company (100–500 employees, 1–3 sites): 14–22 weeks
• Large IT services / BPO (500–5,000 employees, multi-site): 20–32 weeks
• BFSI / healthcare / e-commerce with complex data environments: 18–30 weeks
• ISO 27001:2013 → 2022 transition: 8–14 weeks
• Combined ISO 27001:2022 + ISO 27701:2019: Add 6–10 weeks

Cost components:

• PrecisionTech consulting fees: Scope-based fee determined after initial gap assessment. Transparent fee proposal provided upfront. Fees scale with scope size and complexity.
• Certification body audit fees (NABCB-accredited CB — BSI, Bureau Veritas, SGS, TÜV SÜD, DNV): Stage-1 + Stage-2 + Year 1 surveillance + Year 2 surveillance. For a 100-person IT company: INR 1,20,000–2,50,000 for initial certification. For a 1,000-person company: INR 3,00,000–7,00,000. Multi-site increases fees.
• Technology investment: Depends on gaps — SIEM implementation (open-source options: Elastic SIEM, Wazuh; commercial: Microsoft Sentinel, Splunk), MDM for mobile device management, PAM tool for large organisations, vulnerability scanning tool. Many organisations find their existing tools (Microsoft 365 Defender, AWS Security Hub) cover significant IS controls without additional investment.
• Training investment: IS awareness training platform (KnowBe4, Proofpoint, or custom), phishing simulation, developer secure coding training (SANS, OWASP courses)

ROI of ISO 27001:2022 certification:

• Revenue enablement: Access to tenders, contracts, and market segments requiring ISO 27001 certification. For IT services companies, the certification unlocks BFSI, healthcare, and government client tenders — commonly the highest-margin segments.
• Cyber insurance premium reduction: ISO 27001 certification is recognized by cyber insurance underwriters — premium reductions of 10–25% are documented for certified organisations.
• Breach cost reduction: IBM's Cost of a Data Breach Report 2023 found organisations with a high level of security maturity (approximated by ISO 27001-like implementations) had 40–60% lower breach costs than low-maturity organisations.
• Regulatory compliance efficiency: A single ISMS framework addresses CERT-In, DPDPA, RBI/SEBI/IRDAI requirements simultaneously — reducing regulatory compliance cost vs. addressing each separately.

Business continuity and ICT resilience appear in ISO 27001:2022 through Annex A controls A.5.29 (Information security during disruption), A.5.30 (ICT readiness for business continuity — new 2022 control), and A.8.13 (Information backup). These controls ensure that the ISMS continues to function during disruptions and that information systems can recover within defined timeframes.

A.5.29 — Information Security During Disruption:

The organisation must plan how information security will be maintained during adverse situations — disasters, severe incidents, pandemics. This covers: maintaining IS controls during incident response (ensuring that emergency procedures do not bypass critical security controls, e.g., not sharing credentials in a crisis), maintaining IS policies during crisis (remote working security, third-party emergency access controls), and IS incident management during disruption.

A.5.30 — ICT Readiness for Business Continuity (NEW in ISO 27001:2022):

ICT continuity planning to support business continuity — the most significant new BCP-related control in the 2022 edition. Requires:

• Defining Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each critical information system based on Business Impact Analysis (BIA)
• Designing recovery architecture to meet defined RTO/RPO — high availability (active-active), warm standby (active-passive), or cold standby with defined recovery time
• Testing ICT recovery procedures — backup restoration tests, DR failover tests, table-top exercises
• Documenting ICT recovery plans — who initiates recovery, what steps, in what order, with what resources
• Integrating ICT continuity into the broader BCP — ICT recovery is not separate from business recovery

A.8.13 — Information Backup:

• Backup policy covering: what is backed up, backup frequency (aligned with RPO), backup media/storage, backup location (offsite or cloud — different from primary data location), encryption of backup data
• Backup restoration testing — at minimum annual full restoration test with documented results. The most common finding is organisations with backup systems that have never been tested for restoration — "we know the backup is running but have never confirmed it can actually restore."
• Backup access control — backups must be protected from modification or deletion (ransomware commonly targets backups). Immutable backup storage (AWS S3 Object Lock, Azure Blob immutability, tape with air-gap) is best practice.

ISO 22301:2019 — Business Continuity Management System:

ISO 22301:2019 is the full Business Continuity Management System standard — covering business continuity for the entire organisation, not just ICT. ISO 27001:2022 Annex A BCM controls (A.5.29, A.5.30) are a subset of what ISO 22301 requires. For organisations pursuing both certifications: ISO 22301 provides the overarching BCMS framework, while ISO 27001 A.5.30 covers the ICT-specific subset within that framework. Combined ISO 27001 + ISO 22301 certification (BCMS+ISMS) is offered by NABCB-accredited certification bodies and is particularly common in financial sector organisations where both information security and business continuity are regulatory requirements (RBI BCP requirements for banks, SEBI for market infrastructure).

PrecisionTech's ISO 27001:2022 consulting methodology is built around a fundamental principle: an ISMS that manages information security risks in practice — not just one that produces certification documentation. The most common failure in ISO 27001 consulting is a documentation-heavy approach that passes Stage-2 audits but leaves the organisation with no genuine security improvement. Our approach is different.

1. Risk-Driven Implementation — Not Template-Driven:

Every ISMS we build starts with the risk assessment — identifying the actual information security risks facing the specific organisation in its specific context. We do not apply a standard template set of controls for all clients. A 50-person fintech's significant risks (payment fraud, credential compromise, API security) are different from a 500-person BPO's (data exfiltration by insiders, client data breach, ransomware on shared infrastructure). Control selection is calibrated to the actual risk profile.

2. SoA Built for Audit Survival — Not Checkbox Completeness:

We build SoAs with bidirectional traceability — from every risk in the register to the controls in the SoA, and from every control in the SoA to the evidence of its implementation. When the Stage-1 auditor asks "why is A.8.12 (DLP) not applicable?" we have a documented, credible answer. When the Stage-2 auditor asks for evidence of A.5.18 (access reviews), we have dated records, not a policy that says reviews should happen.

3. Technical Evidence-Ready Implementation:

Certification auditors test technical controls with evidence — screenshots, configuration exports, tool outputs, access review records. We implement controls in a way that produces audit-ready evidence by design — not as an afterthought. Our SIEM configurations, patch management reports, and access review processes produce the specific evidence formats that ISO 27001 auditors expect.

4. India-Specific Regulatory Integration:

We build CERT-In compliance (6-hour incident reporting, 180-day log retention, NTP synchronisation) and DPDPA 2023 obligations (data deletion, data masking, data processor agreements) directly into the ISMS — so that ISO 27001:2022 certification simultaneously advances regulatory compliance for all applicable Indian frameworks. One ISMS, multiple compliance outcomes.

5. Right-Sized for Operational Sustainability:

An ISMS that is too burdensome is abandoned by the organisation after the certification auditor leaves — causing surveillance audit failures. We design ISMS processes that organisations can maintain with their existing team — automated where possible (automated access reviews, automated vulnerability scanning, automated policy distribution and completion tracking), documented in a way that is clear to non-IS specialists, and proportionate to the organisation's size and risk profile.

6. Post-Certification Continuity — Annual Surveillance Programme:

ISO 27001 is a 3-year certification cycle with annual surveillance audits. PrecisionTech provides annual maintenance: risk register quarterly updates, SoA review for new systems and services, IS awareness training refresh, vulnerability assessment review, internal audit conduct, management review facilitation, and surveillance audit preparation. Clients who maintain their ISMS with PrecisionTech's support consistently achieve surveillance audits with zero major non-conformities.

The transition deadline from ISO/IEC 27001:2013 to ISO/IEC 27001:2022 is October 31, 2025. This deadline was set by the International Accreditation Forum (IAF) as a three-year transition period from the October 2022 publication of the new edition.

What happens after October 31, 2025:

• All ISO/IEC 27001:2013 certificates become invalid — regardless of their stated expiry date on the certificate
• NABCB (India's national accreditation body) will withdraw accreditation from certification bodies for the 2013 edition
• Certification bodies will no longer be able to issue surveillance audit reports against the 2013 edition — any organisation that attempts a Year 1 or Year 2 surveillance audit after October 2025 against the 2013 edition will not receive a valid audit result
• Customers and tender committees increasingly aware — procurement specifications will reference ISO 27001:2022 specifically

What is the transition process:

• Step 1: Conduct a 2013 → 2022 gap assessment — identify which new controls (especially the 11 new Annex A controls) apply and which existing controls need updating for the 2022 revised text
• Step 2: Update the SoA — rebuild against the 93 Annex A 2022 controls. Map existing 2013 controls to 2022 equivalents using the correspondence table in ISO 27001:2022 Annex B.
• Step 3: Implement the applicable new controls — particularly A.5.7 (Threat intelligence), A.5.23 (Cloud services), A.5.30 (ICT continuity), A.8.9 (Configuration management), A.8.12 (DLP), A.8.16 (Monitoring), A.8.28 (Secure coding)
• Step 4: Update Clause 6.3 (new Planning of Changes clause) — add a documented change management process for ISMS changes
• Step 5: Internal audit under ISO 27001:2022 using updated checklist
• Step 6: Management review under ISO 27001:2022
• Step 7: Request transition audit from CB — may be combined with the next scheduled surveillance audit or require a separate transition assessment. After successful transition audit, a new certificate referencing ISO/IEC 27001:2022 is issued.

Urgency assessment for Indian organisations as of 2025:

• Organisations with October 2025 or later surveillance audit dates must ensure the CB schedules the audit against the 2022 edition
• Organisations with surveillance audits completed before October 2025 against the 2013 edition may still have valid certificates temporarily — but must complete transition before October 31, 2025
• The October 2025 deadline is firm — there is no IAF extension for this transition (unlike some previous standard transitions)

Action required immediately:

• Contact your certification body to confirm your transition plan and scheduling
• Engage PrecisionTech for the 2013 → 2022 gap assessment — the gap assessment takes 1–2 weeks and produces the precise list of new requirements that need implementation
• Begin the transition project — typical transition timeline 8–14 weeks from gap assessment to transition audit

PrecisionTech provides a rapid transition gap assessment that produces a precise implementation plan with effort estimates — enabling organisations to commit to a realistic transition schedule before the October 2025 deadline.

ISO 27001:2022 requires specific "documented information" — the standard's term for policies, procedures, records, and other documented content. The required documented information spans both the clause requirements (Clauses 4–10) and the Annex A controls selected in the SoA.

Mandatorily documented information from Clauses 4–10:

• ISMS scope (Clause 4.3)
• Information security risk assessment process (Clause 6.1.2)
• Information security risk treatment process (Clause 6.1.3)
• Information security objectives (Clause 6.2)
• Evidence of competence (Clause 7.2)
• Documented information for operational planning and control (Clause 8.1)
• Results of information security risk assessments (Clause 8.2) — the risk register
• Results of information security risk treatment (Clause 8.3) — the risk treatment plan
• Evidence of monitoring, measurement, analysis, evaluation results (Clause 9.1)
• Internal audit programme and audit results (Clause 9.2)
• Evidence of management reviews and their results (Clause 9.3)
• Evidence of corrective actions (Clause 10.2)
• Statement of Applicability (Clause 6.1.3(d))

Policy suite typically required for a comprehensive ISMS (Annex A control-driven):

• Information Security Policy (master policy — Annex A.5.1)
• Acceptable Use Policy — A.5.10
• Access Control Policy — A.5.15
• Password/Authentication Policy — A.5.17
• Clear Desk and Clear Screen Policy — A.7.7
• Asset Management Policy — A.5.9
• Information Classification and Handling Policy — A.5.12, A.5.13
• Data Retention and Deletion Policy — A.5.12, A.8.10
• Cryptography and Encryption Policy — A.8.24
• Mobile Device and BYOD Policy — A.8.1
• Remote Working Policy — A.6.7
• Information Security Incident Management Policy — A.5.24
• Business Continuity and DR Policy — A.5.29, A.5.30
• Supplier Security Policy — A.5.19
• Physical Security Policy — A.7.1, A.7.2
• Patch and Vulnerability Management Policy — A.8.8
• Change Management Policy — A.8.32
• Backup Policy — A.8.13
• Network Security Policy — A.8.20
• Secure Software Development Policy (if in scope) — A.8.25–A.8.28
• Data Classification and Handling Procedure
• User Access Management Procedure (provisioning, de-provisioning, access review)
• Incident Response Procedure (including CERT-In notification)
• Business Impact Analysis and BCP/DR Procedure
• Supplier Security Assessment Procedure
• Internal IS Audit Procedure
• IS Risk Assessment and Treatment Procedure

Common documentation non-conformities:

• Policies exist but are not approved by management — no management signature or dated approval record
• Policies more than 12–24 months old without a review record
• Policies not communicated to all relevant personnel — no distribution or acknowledgement records
• Procedures exist at policy level only — no operational procedures describing how the control is actually implemented in practice
• Document control not applied — no version numbers, no review dates, no document owner

PrecisionTech provides a complete IS policy suite library (30+ templates) customised for each client's industry, size, and technology environment — with management approval tracking, version control, and employee acknowledgement systems built in.