ISO/IEC 27001 Information Security
ISMS Certification · Risk Assessment · Annex A Controls

ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS), published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It specifies the requirements for establishing, implementing, maintaining, and continually improving an ISMS — a framework of policies, processes, and controls that organisations use to systematically manage information security risks.

The current editions are ISO/IEC 27001:2013 and its replacement ISO/IEC 27001:2022 (published October 2022). Organisations certified to the 2013 version must transition to the 2022 version by October 2025 (the three-year transition period set by IAF).

What an ISMS does:

• Protects the CIA triad: Confidentiality (information accessible only to authorised users), Integrity (accuracy and completeness of information), Availability (information accessible when needed)
• Risk-based approach: Rather than prescribing a fixed set of controls, ISO 27001 requires you to identify your specific information security risks and select proportionate controls to treat them
• Annex A controls: A reference set of 93 controls (ISO 27001:2022) or 114 controls (ISO 27001:2013) across domains covering organisational, people, physical, and technological security
• Continuous improvement: The ISMS follows the Plan-Do-Check-Act cycle — security posture improves measurably year over year
• Certification: An accredited third-party certification body verifies that your ISMS meets all requirements through Stage-1 and Stage-2 audits, followed by annual surveillance

ISO 27001 is the most widely recognised information security standard globally — accepted by enterprise buyers, regulators (RBI, SEBI, IRDAI in India; GDPR in EU), and government procurement bodies as evidence of structured information security management.

ISO/IEC 27001:2022 was published in October 2022, replacing ISO/IEC 27001:2013. While the core clauses (4–10) remain largely similar, the changes are significant enough to require a formal transition audit:

Key changes in ISO 27001:2022:

1. Annex A restructured (most visible change):

• 2013: 114 controls across 14 domains → 2022: 93 controls across 4 themes (Organisational, People, Physical, Technological)
• 11 new controls added (e.g., threat intelligence, cloud security, ICT supply chain security, data masking, monitoring activities, physical security monitoring, configuration management, information deletion, web filtering, secure coding)
• Several controls were merged or reworded; none were removed

2. Clause-level changes:

• Clause 6.3: New requirement to plan changes to the ISMS in a controlled manner
• Clause 9.3: Management review inputs restructured to be more explicit
• Minor editorial changes throughout for clarity

3. Attributes added to Annex A controls: Each control now has attributes (control type: preventive/detective/corrective; information security properties: CIA; cybersecurity concepts; operational capabilities; security domains) to support different risk management approaches and frameworks.

Transition deadline: The IAF (International Accreditation Forum) has set October 31, 2025 as the deadline for transition. After this date, all ISO 27001 certifications must be to the 2022 version. Organisations certified to 2013 must complete a transition audit before this deadline or their certificate lapses.

How PrecisionTech helps with 2022 transition:

• Gap analysis against 11 new controls and changed clause requirements
• Updated Statement of Applicability incorporating 2022 control structure
• Policy and procedure updates for new controls
• Transition audit coordination with your certification body

ISO 27001 uses the Annex SL 10-clause high-level structure. Clauses 1–3 are informative (scope, references, terms). Clauses 4–10 are mandatory requirements:

Clause 4 — Context of the Organisation: Understand internal and external context (business environment, regulatory landscape, threat landscape). Identify interested parties and their security requirements. Define the ISMS scope — what assets, processes, locations, and interfaces are inside the boundary. Document the ISMS and its processes.

Clause 5 — Leadership: Top management must demonstrate active leadership of the ISMS — not just sponsor it. Establish the Information Security Policy. Assign ISMS roles and responsibilities. A management representative is not mandatory, but roles must be clearly defined.

Clause 6 — Planning: Perform information security risk assessment. Develop the risk treatment plan. Select Annex A controls and justify selections in the Statement of Applicability (SoA). Set information security objectives with measurement plans. ISO 27001:2022 added Clause 6.3 — planned changes to the ISMS must be managed in a controlled way.

Clause 7 — Support: Provide resources. Define and verify competence of ISMS-relevant personnel. Maintain security awareness programme for all staff. Manage documented information — the ISMS requires specific mandatory documents and records.

Clause 8 — Operation: Plan and control operational processes. Execute the risk assessment and treatment plan. Manage operational changes. Maintain records of risk assessments performed.

Clause 9 — Performance Evaluation: Monitor and measure ISMS performance and control effectiveness. Define information security KPIs. Conduct internal ISMS audits at planned intervals. Top management performs formal management review.

Clause 10 — Improvement: Address nonconformities with root cause corrective action. Continually improve ISMS suitability, adequacy, and effectiveness based on all performance inputs.

This is one of the most commonly misunderstood aspects of ISO 27001. A risk assessment and a vulnerability scan are fundamentally different activities that serve different purposes — though both contribute to information security management.

ISO 27001 Risk Assessment (Clause 6.1.2):

• A business-level exercise that identifies what could harm your information assets, evaluates likelihood and impact, and prioritises risk treatment actions
• Starts with your information assets: what data do you hold? Customer PII, financial records, IP, operational data, employee data, system configurations
• Identifies threats (cyberattack, insider threat, accidental disclosure, system failure, physical theft, supply chain compromise) and vulnerabilities (weak access controls, unpatched systems, no encryption, poor supplier contracts)
• Assesses risk level (likelihood × impact) using a defined methodology that must be consistent and repeatable
• Selects treatment options: apply controls (from Annex A), avoid the risk, transfer (cyber insurance, outsource), or accept with documented rationale
• Output: Risk Register (live document, reviewed at least annually or when significant changes occur) and Risk Treatment Plan (linked to Annex A controls)

Vulnerability Scan / Penetration Test:

• A technical exercise that identifies specific technical weaknesses in systems, networks, or applications
• Provides input INTO the risk assessment — vulnerabilities identified in a pentest inform your risk register
• ISO 27001:2013 Annex A.12.6 (vulnerability management) and ISO 27001:2022 Control 8.8 require you to manage technical vulnerabilities — but the scan itself is not the risk assessment

Both are needed: Risk assessment gives you the strategic view of what to protect and prioritise. Vulnerability scanning gives you the technical evidence to support risk levels and demonstrate control effectiveness.

PrecisionTech develops your risk assessment methodology and risk register as part of ISMS implementation — and can coordinate technical vulnerability assessment services if required.

The Statement of Applicability (SoA) is the document that links your risk treatment decisions to specific Annex A controls. It is arguably the most important single document in your ISO 27001 ISMS — auditors spend significant time reviewing it, and it is the cornerstone of your certification.

What the SoA must contain:

• A list of all Annex A controls (114 in ISO 27001:2013; 93 in ISO 27001:2022)
• For each control: whether it is included or excluded from your ISMS
• For included controls: justification for inclusion (which risks it addresses, regulatory requirement, contractual obligation, or business decision)
• For excluded controls: justification for exclusion (why the control is not applicable to your context — e.g., "A.11.1 Physical security controls — not applicable as organisation is fully remote with no physical premises")
• Implementation status: whether the control is currently implemented, partially implemented, or planned
• Reference to where the control is implemented: policy name, system, procedure, or technical measure

Why the SoA is critical:

• It is the audit roadmap — the certification body uses the SoA to plan what evidence to request during Stage-2
• It demonstrates that your risk treatment decisions are systematic and justified — not arbitrary
• It connects your risk register (the risks) to your control set (the mitigations) — the chain of evidence that proves your ISMS is risk-based
• Incorrect or incomplete SoA is one of the most common causes of major non-conformities at Stage-1

PrecisionTech develops the SoA as a core deliverable of the ISMS implementation — ensuring every control is properly assessed, justifications are documented, and the SoA accurately reflects your implemented controls before the certification audit.

Annex A of ISO/IEC 27001:2013 provides a reference set of 114 information security controls organised across 14 control domains (also called sections or clauses of ISO/IEC 27002:2013). These are not all mandatory — you select which controls to include based on your risk treatment decisions, as documented in your SoA.

The 14 Annex A domains (ISO 27001:2013):

• A.5 — Information Security Policies (2 controls): Management direction for information security; regular review of policies
• A.6 — Organisation of Information Security (7 controls): Security roles and responsibilities; segregation of duties; contact with authorities; mobile working and remote access
• A.7 — Human Resource Security (6 controls): Pre-employment screening; terms of employment; disciplinary process; termination and role change procedures
• A.8 — Asset Management (10 controls): Asset inventory; ownership; classification; acceptable use; handling; media disposal
• A.9 — Access Control (14 controls): Access control policy; user provisioning; privileged access management; password management; segregation of access
• A.10 — Cryptography (2 controls): Policy on cryptographic controls; key management
• A.11 — Physical and Environmental Security (15 controls): Secure areas; physical access control; equipment security; clean desk/clear screen; cable security
• A.12 — Operations Security (14 controls): Change management; capacity management; malware protection; backup; logging and monitoring; vulnerability management; audit logging
• A.13 — Communications Security (7 controls): Network controls; segregation; information transfer; NDAs; messaging security
• A.14 — System Acquisition, Development and Maintenance (13 controls): Security requirements for systems; secure development; change control; test data; code review
• A.15 — Supplier Relationships (5 controls): Security in supplier agreements; monitoring supplier services; supply chain security
• A.16 — Information Security Incident Management (7 controls): Responsibilities and procedures; incident reporting; response and recovery; evidence collection
• A.17 — Business Continuity Management (4 controls): Planning continuity; implementing continuity; testing continuity; redundancies
• A.18 — Compliance (8 controls): Legal and contractual requirements; intellectual property; privacy and personal data; security reviews

Note on ISO 27001:2022: The 2022 version restructures Annex A into 4 themes (Organisational, People, Physical, Technological) with 93 controls — 11 new controls were added covering areas like threat intelligence, cloud security, and secure coding. The underlying security intent is largely the same; the structure is cleaner and better aligned with modern security operations.

ISO 27001 requires specific mandatory documented information (policies and records). The total number of documents in a typical ISMS implementation depends on the scope and complexity of the organisation — but here is what is mandatory and what is typically recommended:

Mandatory documented information (ISO 27001:2013):

• ISMS scope document (Clause 4.3)
• Information Security Policy (Clause 5.2)
• Risk assessment methodology (Clause 6.1.2)
• Risk Register (Clause 6.1.2 — records)
• Risk Treatment Plan (Clause 6.1.3 — records)
• Statement of Applicability — SoA (Clause 6.1.3)
• Information security objectives (Clause 6.2)
• Competence evidence — training records (Clause 7.2)
• Internal audit programme and results (Clause 9.2)
• Management review records (Clause 9.3)
• Nonconformity and corrective action records (Clause 10.1)
• Monitoring and measurement results (Clause 9.1)

Typically recommended supporting policies (not explicitly listed but required by Annex A controls):

• Acceptable Use Policy (A.8.1.3)
• Access Control Policy (A.9.1.1)
• Information Classification and Handling Policy (A.8.2)
• Cryptography Policy (A.10.1.1)
• Clear Desk and Clear Screen Policy (A.11.2.9)
• Backup Policy (A.12.3.1)
• Mobile Device and Remote Working Policy (A.6.2.1/A.6.2.2)
• Secure Development Policy (A.14.2.1)
• Supplier Security Policy (A.15.1.1)
• Incident Response Plan and Procedure (A.16.1.1)
• Business Continuity Plan (A.17.1)
• User Registration and Deregistration Procedure (A.9.2.1)
• Vulnerability Management Procedure (A.12.6.1)

Typical document count for an SME ISMS:

• Core policies: 12–18 policy documents
• Procedures and SOPs: 8–15 procedure documents
• Templates and forms: 10–20 templates
• Records: Maintained continuously (risk register, audit reports, training records, incident log, etc.)

PrecisionTech develops all mandatory and recommended documents tailored to your specific organisation — not generic templates with placeholder text.

ISO 27001 was designed to be technology-neutral and applies fully to cloud-first and SaaS organisations. However, cloud environments introduce specific complexity that requires careful ISMS scope definition, shared responsibility management, and additional technical controls.

ISMS Scope for cloud organisations:

• Scope must explicitly include cloud services — AWS, Azure, GCP, and any SaaS tools in scope (e.g., CRM, HRIS, financial systems)
• Shared responsibility model must be documented: cloud provider responsibilities (physical security, hypervisor) vs. your responsibilities (IAM, data encryption, application security, network configuration)
• Cloud service provider (CSP) agreements must be evaluated under Annex A.15 (Supplier Relationships) and include security requirements, breach notification obligations, and audit rights

Key Annex A controls for cloud environments:

• A.9 — Access Control: MFA mandatory for all cloud console access; IAM roles and least-privilege; service accounts with minimal permissions; regular access reviews
• A.10 — Cryptography: Encryption for data at rest (S3, RDS, storage volumes) and in transit (TLS 1.2+); key management (AWS KMS, Azure Key Vault); secrets management (HashiCorp Vault, AWS Secrets Manager)
• A.12 — Operations Security: Cloud-native logging (CloudTrail, Azure Monitor, GCP Cloud Audit Logs); SIEM integration; vulnerability scanning of cloud infrastructure; patch management for cloud-hosted systems
• A.13 — Network Security: VPC/network segmentation; security group and firewall configuration baselines; WAF for web applications; DDoS protection
• A.14 — Secure Development: Infrastructure as Code (IaC) security reviews; SAST/DAST in CI/CD pipelines; container image scanning; SBOM management

ISO 27001:2022 new controls especially relevant for cloud:

• 8.23 — Web filtering: Control access to external websites from organisational systems
• 8.25 — Secure development life cycle: Security built into the SDLC — not bolted on
• 5.23 — Information security for use of cloud services: NEW control specifically addressing cloud governance
• 5.30 — ICT readiness for business continuity: Cloud-specific resilience planning (multi-region, RTO/RPO)

Additional frameworks for cloud: ISO/IEC 27017 (cloud security controls, extends 27001/27002), ISO/IEC 27018 (privacy in cloud services — relevant for processing customer personal data in cloud).

PrecisionTech has specific experience implementing ISO 27001 for SaaS companies, cloud-hosted applications, and cloud-first IT infrastructure — designing controls appropriate for the shared responsibility model.

ISO 27001 Clause 9.2 requires organisations to conduct internal ISMS audits at planned intervals to verify that the management system conforms to requirements and is effectively implemented. This is a compliance audit — not a technical security assessment.

What ISMS internal audits cover:

• Clause-by-clause verification that all ISMS requirements (Clauses 4–10) are implemented and evidenced
• Control-by-control sampling of Annex A controls marked as applicable in the SoA — verifying that each control is actually implemented as documented and effective
• Records review: are risk assessments current? Is the training log complete? Are incident records maintained? Are corrective actions tracked and closed?
• Interviews with process owners and staff: do they understand their ISMS responsibilities? Do they know how to report incidents?
• Output: internal audit report with findings (conforming/observation/non-conformity), non-conformity reports, corrective action requests

How internal audit differs from penetration testing:

• Internal audit: Asks "Is the control documented, implemented, and effective?" — a compliance check
• Penetration test: Asks "Can an attacker actually exploit a vulnerability?" — a technical security assessment
• Both are required under ISO 27001 — internal audit for clause compliance, penetration testing as evidence for specific technical controls (A.12.6, A.14.2.8)
• Internal audit findings may identify that penetration testing is not being conducted as required — and raise a non-conformity against the Annex A control

Who can conduct ISMS internal audits:

• Internal auditors must be competent and impartial — they cannot audit their own work
• Lead Auditor or Internal Auditor training for ISO 27001 (typically 3–5 day course) provides the competence base
• External consultants (like PrecisionTech) can conduct internal audits — particularly valuable for organisations without trained internal ISMS auditors

PrecisionTech conducts ISMS internal audits as a consulting service — comprehensive clause-by-clause and SoA control-by-control verification, with findings reported in a format ready for certification body review.

ISO/IEC 27001 certification has strong alignment with multiple Indian regulatory frameworks and international compliance requirements:

Indian regulatory alignment:

• RBI (Reserve Bank of India): RBI's Cybersecurity Framework for Banks (2016), Master Direction on IT (2023), and guidelines for NBFCs all reference security management system requirements that align closely with ISO 27001 Annex A controls — particularly access control, incident management, patch management, data backup, and audit logging
• SEBI (Securities and Exchange Board of India): SEBI's Cybersecurity and Cyber Resilience Framework for market infrastructure institutions (MIIs) recommends ISO 27001 or equivalent frameworks
• IRDAI (Insurance Regulatory and Development Authority of India): IRDAI's Guidelines on Information and Cyber Security for Insurers align with ISO 27001 domains
• MeitY (Ministry of Electronics and IT): CERT-In guidelines and NIC security policies reference ISO 27001 equivalent controls; government IT projects increasingly require ISO 27001 certification from vendors
• IT Act 2000 and amendments: Section 43A on reasonable security practices and procedures aligns with ISO 27001 implementation (ISO 27001 is listed as an acceptable standard in the Rules)

India Digital Personal Data Protection (DPDP) Act, 2023:

The DPDP Act, 2023 requires "Data Fiduciaries" to implement reasonable security safeguards to prevent personal data breaches. ISO 27001 provides the structural framework for implementing these safeguards — making ISO 27001 certification a strong demonstration of compliance intent:

• ISO 27001 Annex A controls cover data access controls, encryption, breach detection, incident response, and supplier security — all critical for DPDP compliance
• For organisations processing sensitive personal data or large volumes of personal data, ISO 27001 + ISO/IEC 27701 (Privacy Information Management System extension) provides the most comprehensive compliance framework
• ISO 27001 certification does not guarantee DPDP Act compliance — the Act has specific requirements for notice, consent, data principal rights, and data localisation — but it significantly addresses the security obligation

International frameworks:

• GDPR (EU): ISO 27001 + ISO/IEC 27701 provides strong GDPR Article 32 (security) compliance evidence
• SOC 2: ISO 27001 controls map to SOC 2 Trust Services Criteria (Security, Availability, Confidentiality); many organisations pursue both for different markets
• HIPAA: ISO 27001 technical safeguards align with HIPAA Security Rule requirements for ePHI protection

The certification timeline depends on four key variables: (1) scope complexity, (2) current security maturity, (3) team availability and engagement speed, and (4) certification body scheduling. Realistic ranges for Indian organisations:

Small organisations (up to 25 staff, simple IT footprint, single site):

• Starting from low maturity: 4–6 months from project start to Stage-2 audit
• Existing policies and security awareness: 2–4 months

Medium organisations (25–200 staff, cloud or hybrid infrastructure, 1–2 sites):

• Starting from low maturity: 6–10 months
• Existing partial controls (firewall, MFA, antivirus): 4–7 months

Large or complex organisations (200+ staff, multi-site, complex cloud, regulatory drivers):

• 8–18 months depending on scope, regulatory complexity, and resource availability

What drives the timeline:

• Risk assessment completion: The most time-consuming step — requires asset inventory, threat identification, risk rating, and treatment planning. Cannot be rushed without compromising quality.
• Control implementation gaps: If you have no MFA, no logging, no vulnerability management — these technical controls take time to implement before the ISMS can evidence them
• Documentation development: 3–6 weeks for a complete policy suite from scratch
• ISMS operation period: Certification bodies typically require evidence that the ISMS has been operational for at least 3 months before Stage-2 (including at least one completed internal audit and management review)
• Certification body scheduling: NABCB-accredited bodies have 4–8 week lead times for audit scheduling

Common delays:

• Asset inventory taking longer than expected (shadow IT, undocumented cloud services)
• Technical vulnerability remediation before audit (organisations find issues they cannot leave open)
• Staff awareness training engagement — getting all employees to complete training
• Supplier security assessment backlogs

PrecisionTech creates a realistic milestone-based project plan at the start and actively manages progress to keep the certification timeline on track.

ISO 27001 Clause 7.3 requires all persons doing work under the organisation's control to be aware of: the information security policy; their contribution to the ISMS effectiveness; and the implications of not conforming with ISMS requirements. Additionally, Annex A.7.2.2 (2013) requires an awareness education and training programme.

What effective ISO 27001 security awareness training covers:

• Core ISMS concepts: What is information security? What is the CIA triad? Why does it matter to the organisation and to each individual?
• Information security policy: Staff must know the policy exists, understand its key requirements, and know where to find it
• Asset and data handling: How to classify information (confidential, internal, public); how to handle different classifications; clean desk/clear screen; secure disposal of documents and devices
• Access control and passwords: Why strong passwords matter; password manager usage; MFA; not sharing credentials; formal access request and revocation procedures
• Phishing and social engineering: How to recognise phishing emails, phone scams, and pretexting; what to do if you receive a suspicious communication
• Incident reporting: What constitutes an information security incident; how and where to report it; why prompt reporting is critical
• Mobile device and remote working security: Secure Wi-Fi usage; VPN requirements; device encryption; lock screens
• Acceptable use: What is and isn't allowed on company systems and networks

Evidence requirements for auditors:

• Training attendance records or completion logs (by name, date, training topic)
• For online training: completion certificates with timestamps
• Phishing simulation results (if used) — improvement trend over time
• For new joiners: records showing awareness training was completed during onboarding

Frequency: Annual full awareness training for all staff is the baseline. Targeted awareness (e.g., phishing simulation follow-up, new threat communications) can be more frequent.

PrecisionTech designs security awareness training programmes and provides training delivery support — covering all requirements for ISO 27001 compliance evidence.

Supplier security (Annex A.15 in ISO 27001:2013; Controls 5.19–5.22 in ISO 27001:2022) is one of the most commonly under-implemented areas — and one that certification body auditors probe carefully, particularly for organisations with extensive cloud and SaaS dependencies.

What ISO 27001 requires for supplier security:

• Supplier assessment before engagement: Evaluate security risks posed by each supplier before sharing information or granting access. Not all suppliers need the same level of assessment — tier them by risk (critical, significant, standard)
• Security requirements in contracts: All contracts with suppliers who access, process, or handle your information must include: confidentiality/NDA obligations, security standards required, breach notification timelines, right to audit, data deletion on contract end, incident communication procedures
• Ongoing monitoring: Periodically review critical suppliers — annual assessment, security questionnaires, review of their certifications (ISO 27001, SOC 2), and monitoring of security incidents affecting them
• Supply chain security (new in ISO 27001:2022 Control 5.21): Manage security risks in the ICT supply chain — software and hardware vendors, open-source components, cloud service providers

Common supplier security gaps found in audits:

• No formal supplier register or risk classification
• NDAs in place but no security-specific clauses in service agreements
• Critical SaaS tools (CRM, HRIS, project management) not assessed or contracted with security requirements
• No periodic review — supplier assessment done once at onboarding and never repeated
• No process for managing supplier security incidents

Practical supplier management approach for SMEs:

• Tier 1 (Critical — data access, admin access to systems): Annual security questionnaire, contract review, incident notification SLA
• Tier 2 (Significant — limited data access, supporting services): Contract security clauses, biennial review
• Tier 3 (Standard — no data access): Register, standard terms sufficient

ISO 27001 Annex A.17 (Business Continuity Management — ISO 27001:2013) and Controls 5.29–5.30 (ISO 27001:2022) require organisations to plan and implement business continuity specifically for information security — ensuring that critical information security processes and controls remain effective during and after disruptive incidents.

What ISO 27001 requires for business continuity (BCDR):

• A.17.1.1 — Planning IS continuity: Determine how the organisation will maintain IS during adverse situations. Identify critical processes and their IS requirements. Set RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for critical systems.
• A.17.1.2 — Implementing IS continuity: Document, implement, and maintain continuity procedures. Include IS-specific controls in the BCP — not just general recovery steps.
• A.17.1.3 — Verify, review and evaluate: Test continuity procedures at planned intervals. Document test results and update plans based on findings.
• A.17.2 — Redundancies: Implement redundancy for information processing facilities to meet availability requirements.

ISO 27001 vs ISO 22301 (Business Continuity Management System):

• ISO 27001 A.17 requires you to include IS considerations in your BCP — it does not require a full formal Business Continuity Management System
• ISO 22301 is the dedicated standard for BCMS — comprehensive requirements for all aspects of business continuity (not just IS)
• Many organisations implement ISO 27001 first (IS continuity), then layer ISO 22301 for full enterprise BCMS — or implement both simultaneously under an IMS
• ISO 27001:2022 Control 5.30 (ICT readiness for business continuity) makes the requirement more explicit — ICT continuity plans must be aligned with business continuity objectives

Practical minimum for ISO 27001 BCDR compliance:

• Business Impact Analysis (BIA) identifying critical processes and their IS dependencies
• RTO/RPO defined for critical systems (email, core business applications, data stores)
• Data backup procedure with offsite/cloud backup, tested restoration at least quarterly
• DR plan for critical systems with documented recovery steps
• Annual DR test with documented results and corrective actions

ISO 27001 and SOC 2 are both security assurance frameworks widely recognised by enterprise buyers — but they differ significantly in scope, methodology, market recognition, and cost. Indian IT companies frequently face this choice when serving US or European clients.

ISO/IEC 27001:

• Type: International management system certification — a third-party certification against a published standard
• Scope: Covers the organisation's entire ISMS — all information security management processes and controls
• Output: Certificate valid for 3 years (with annual surveillance audits) — certificate is publicly verifiable on IAF CertSearch
• Market: Recognised globally, especially in EU, UK, Middle East, Australia, and India. Preferred by many European enterprise buyers. Mandated by Indian government IT procurement, RBI, SEBI in some contexts.
• Cost model: One-time consulting + certification body fee + annual surveillance fee
• Framework: Risk-based — you identify and treat risks specific to your context, select relevant Annex A controls

SOC 2 (System and Organization Controls 2):

• Type: AICPA attestation report — a CPA firm attests to your controls against Trust Services Criteria
• Scope: Covers a specific system or service (not necessarily the whole organisation)
• Output: SOC 2 Type I (point-in-time) or SOC 2 Type II (period report — 6 or 12 months of evidence) — shared confidentially with specific clients under NDA
• Market: Preferred by US enterprise buyers — US-listed companies, US VC-backed SaaS, US financial institutions. Less understood in India and Europe.
• Cost model: Annual — new report every year; typically more expensive annually than ISO 27001
• Framework: Controls-based against five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy)

Which should Indian IT companies pursue?

• Serving US enterprise clients primarily: SOC 2 Type II is often the first ask. Consider ISO 27001 as well for broader market appeal.
• Serving EU, UK, or Indian enterprise clients: ISO 27001 is the primary credential. SOC 2 is less commonly required.
• Serving both markets: ISO 27001 + SOC 2 Type II — the controls substantially overlap, making dual certification more efficient than sequential.
• Early-stage startups: ISO 27001 is typically more accessible (faster, lower annual cost) and provides stronger management system discipline alongside the certification.

PrecisionTech can advise on the right sequencing and help implement controls that satisfy both frameworks simultaneously — reducing the overall cost of dual certification.

ISO 27001 Annex A.16 (ISO 27001:2013) and Controls 6.8, 5.24–5.28 (ISO 27001:2022) address information security incident management — the process of detecting, reporting, responding to, and learning from information security incidents.

What ISO 27001 requires for incident management:

• Responsibilities and procedures (A.16.1.1): Documented incident response procedures with clear roles — who declares an incident, who leads the response, who communicates externally (customers, regulators, police), who documents
• Reporting information security events (A.16.1.2): All staff must know how to report a suspected security incident — a reporting channel (email, helpdesk, phone) and a requirement to report promptly without fear of blame
• Reporting information security weaknesses (A.16.1.3): Staff and contractors must also report security weaknesses — things that could lead to an incident even if no breach has yet occurred
• Assessment and decision on events (A.16.1.4): A process for triaging reported events — distinguishing real incidents from false positives; classifying incident severity
• Response to incidents (A.16.1.5): Documented response procedures including containment, evidence preservation, eradication, and recovery steps proportionate to incident severity
• Learning from incidents (A.16.1.6): Post-incident review — root cause analysis, corrective actions, ISMS improvements, and updating incident procedures
• Collection of evidence (A.16.1.7): Evidence preservation procedures for incidents that may require forensic investigation, legal action, or regulatory notification

Regulatory breach notification context for India:

• CERT-In (2022 Directions): Reportable incidents must be notified to CERT-In within 6 hours of detection — a very tight window that requires a pre-planned incident response procedure
• DPDP Act, 2023: Personal data breaches must be notified to the Data Protection Board of India (DPBI) "as soon as possible" — exact timelines in subordinate rules
• RBI (for banks and NBFCs): Cyber incidents must be reported to RBI within 2–6 hours depending on severity

ISO 27001 incident management procedures — when properly implemented — provide the structural framework to meet all these notification timelines, because the detection, assessment, escalation, and notification steps are pre-planned and practised, not improvised during an incident.

Access control is Annex A.9 (14 controls in ISO 27001:2013) and falls primarily under the "Technological" theme in ISO 27001:2022 (Controls 5.15–5.18, 8.2–8.6). It is one of the most heavily audited Annex A domains because inadequate access control is a root cause of the majority of information security breaches.

Procedural requirements (organisational/policy):

• Access control policy (A.9.1.1): Documented policy defining access control principles — least privilege, need-to-know, segregation of duties, formal access authorisation process
• User registration and deregistration (A.9.2.1): Formal process for adding and removing user accounts — onboarding triggers provisioning, role change triggers re-provisioning, offboarding triggers immediate de-provisioning
• Periodic access reviews (A.9.2.5): Regular (typically quarterly or semi-annual) reviews of all user access rights — especially privileged accounts and access to sensitive data — by system/data owners. Excessive access is removed.
• Privileged access management (A.9.2.3): Separate, more tightly controlled process for administrator and root accounts — just-in-time access, separate accounts for admin vs normal use, all privileged actions logged

Technical controls:

• Multi-Factor Authentication (MFA): Mandatory for all cloud console access (AWS, Azure, GCP, Microsoft 365), VPN, remote desktop, and access to sensitive applications
• Single Sign-On (SSO): Centralised identity management for SaaS applications — easier to provision, de-provision, and audit access centrally
• Password policy: Minimum length, complexity, no reuse; password manager recommended for users
• Role-Based Access Control (RBAC): Access granted based on job role, not individually negotiated
• Network segmentation: Critical systems on separate network segments from general user network; developer systems separated from production

Common access control non-conformities found in audits:

• Former employees still having active accounts (offboarding not followed consistently)
• Shared passwords or credentials for critical systems
• No MFA on cloud administration consoles
• Privileged accounts used for daily work (browsing, email) — should be separate from admin accounts
• No documented evidence of access reviews having been conducted

Understanding common non-conformities helps organisations prioritise their preparation efforts and avoid the most frequent certification blockers. Based on patterns across many ISO 27001 certification audits:

Stage-1 (documentation review) common major non-conformities:

• Undefined or over-broad ISMS scope: Scope that says "all information assets" without defining the boundary — what systems, processes, sites, interfaces are in and out
• No risk assessment methodology documented: Risk assessment performed but not using a documented, consistent, repeatable methodology — auditors cannot assess reproducibility
• Incomplete Statement of Applicability: Missing controls without justification; included controls with no implementation status; SoA that does not reference the risk register or treatment plan
• No information security objectives: Objectives that cannot be measured ("improve security awareness") rather than measurable targets ("95% staff completion of annual awareness training by Q3")
• Missing mandatory documented information: Key procedures or records not existing at all — internal audit programme, management review records

Stage-2 (implementation) common major non-conformities:

• Controls in SoA not actually implemented: SoA says "access reviews conducted quarterly" but no evidence exists that any review has been performed
• Risk assessment not risk-based: Generic risks not linked to actual assets; same risk register for all organisations of same type
• No evidence of training completion: Awareness training "planned" but no completion records for current staff
• Logging not configured or not reviewed: Logging control marked as implemented but no SIEM or log review process in evidence
• Vulnerability management not operational: Control listed as implemented but no scan results, no remediation tracking, no patch compliance metrics
• Supplier contracts without security clauses: Key SaaS or cloud vendors contracted without IS requirements
• Incident management untested: IRP documented but never exercised — no tabletop drill, no incident records, staff unaware of reporting process

PrecisionTech's implementation approach specifically targets these known failure points — ensuring your ISMS has genuine evidence of all implemented controls before Stage-1 or Stage-2 begins.

ISO 27001 certification involves two cost components: consulting fees and certification body fees. Both are variable and depend on your specific context.

Factors that drive consulting cost:

• Organisation size (staff count, number of systems in scope)
• ISMS scope breadth (specific department vs whole organisation)
• Complexity of IT environment (cloud-only vs hybrid vs on-premise; number of applications in scope)
• Current security maturity (starting from scratch vs existing partial controls)
• Regulatory drivers (RBI/SEBI/IRDAI requirements add documentation complexity)
• Number of sites included in scope
• Whether penetration testing is included (recommended but separate cost)
• Speed of project (expedited timelines require more intensive engagement)

Typical consulting fee ranges (India, 2025):

• Small organisation (up to 25 staff, single site, limited cloud): ₹25,000–₹80,000
• SME (25–100 staff, cloud-heavy, 2–5 systems in scope): ₹80,000–₹2,50,000
• Medium organisation (100–300 staff, multi-site or complex cloud): ₹2,50,000–₹7,00,000
• Large/enterprise (300+ staff, enterprise cloud, regulatory drivers): ₹7,00,000+

Certification body fees (NABCB-accredited bodies):

• Driven by audit man-days (IAF MD1 sets minimum audit days by employee count for ISO 27001)
• Typically ranges from ₹40,000–₹1,50,000 for initial certification (Stage-1 + Stage-2) for small to medium organisations
• Annual surveillance audit: approximately 50–60% of initial certification cost

Additional investments often needed:

• Penetration testing (if not done recently): ₹30,000–₹2,00,000 depending on scope
• SIEM or log management tools (if not in place): variable
• MFA implementation for cloud access: often low/no cost using existing platform features
• Security awareness training platform: ₹500–₹1,500 per user per year for commercial platforms

Beware of ₹5,000–₹20,000 "ISO 27001 packages": Non-accredited certificates are not recognised by enterprise buyers, government procurement, or export markets. PrecisionTech only works with NABCB/IAF-accredited certification bodies.

ISO 27001 ISMS implementation requires a rare combination of information security technical depth, compliance and documentation expertise, and organisational change management capability. Generic IT consultants and generic ISO consultants (who focus primarily on ISO 9001) often struggle with the technical nuances that distinguish a robust ISMS from a paper exercise.

What distinguishes PrecisionTech's ISO 27001 consulting:

1. Technical depth in relevant control domains: PrecisionTech has hands-on experience with the technology environments Indian IT and business organisations actually use — AWS, Azure, Microsoft 365, Tally, on-premise servers, network infrastructure. Our Annex A control design is grounded in how these systems actually work, not generic policy language.

2. Risk assessment that reflects actual threat landscapes: We build risk registers that reflect the actual threats to Indian businesses — GST portal fraud, UPI fraud, ransomware targeting SMBs, phishing campaigns specific to India, insider threats in IT services companies — not generic Western threat catalogues.

3. Regulatory alignment built in: We build ISMS documentation that simultaneously addresses ISO 27001 requirements and relevant Indian regulations (CERT-In Directions, DPDP Act, RBI/SEBI/IRDAI requirements) — saving clients the work of mapping between frameworks after certification.

4. Certification audit accompaniment: We attend Stage-1 and Stage-2 audits, respond to auditor observations in real time, provide documentation on demand, and prevent minor documentation gaps from becoming major non-conformities.

5. Complement to our technology practice: PrecisionTech also provides GST GSP API integration, Tally integration, cloud infrastructure (AWS, Azure), and ERP consulting. Our ISO 27001 clients benefit from technology recommendations that are grounded in practical implementation experience — not just policy writing.

6. Long-term AMC: ISO 27001 is a 3-year cycle. PrecisionTech's AMC ensures your ISMS stays relevant through surveillance audits, ISMS updates for new threats, 2022 transition support, and recertification — we are a long-term compliance partner, not a one-engagement vendor.

To start: submit your enquiry via our contact page with your organisation type, approximate staff count, and any specific regulatory or customer drivers. We will respond with an initial assessment call within 48 hours.