ISO 27001 A.5.36: Compliance with Policies, Rules and Standards for Information Security

Quick Reference: A.5.36 in 60 Seconds

What the Standard Actually Requires

Figure · Process

What A.5.36 asks you to do

ISO 27001:2022 Control Text

A.5.36 Compliance with policies, rules and standards for information security

ISO 27001:2022 Annex A 5.36 asks organizations to regularly check that information processing and procedures comply with the organization's security policies, rules, and standards.

This single sentence contains a deep operational obligation. It is not enough to publish policies. The standard demands an active, planned, repeatable process that verifies whether the workforce and systems are behaving in accordance with the documented rules, and that acts on the findings.

ISO 27002:2022 Implementation Guidance

ISO 27002:2022 expands A.5.36 into practical implementation guidance:

1. Compliance reviews should be performed, both through management oversight and independent checks.
2. Automated technical tools should be used where possible to validate configuration and behaviour against policies and standards.
3. Non-compliance should be identified, evaluated, and acted upon through corrective action, disciplinary process, or risk acceptance.
4. Records of compliance reviews should be maintained as evidence for audits and management review.
5. Reviews should be triggered at planned intervals and when significant changes occur (new technology, M&A, new regulation, major incident).

"Shall" vs "Should" Analysis

What Auditors Actually Check

Common Misinterpretations

Why Compliance Monitoring Matters

The Business Risk Narrative

An information security policy that nobody follows is worse than no policy at all. It creates false assurance, liability, and audit failure. A.5.36 is the control that closes the loop between "we wrote the rules" and "people actually follow them."

In Indian organizations, compliance failures can escalate quickly:

• Regulatory action: CERT-In, RBI, SEBI, IRDAI, and the DPDP Board can impose penalties, suspend licences, or bar directors when policy violations lead to breaches.
• Contractual loss: Enterprise customers and global partners increasingly require evidence that policies are not merely documented but enforced through reviews and remediation.
• Operational disruption: A single unchecked exception, a privileged account without MFA, a development team shipping code without review, a supplier accessing systems without a contract, can cascade into a breach.
• Culture decay: When employees see policies ignored by leadership, security awareness collapses and shadow IT flourishes.
• Litigation exposure: Courts and regulators treat documented but unenforced policies as evidence of negligence.

Indian Regulatory Context

Industry-Specific Consequences

impact of Non-Compliance Statistics

• IBM impact of a Data Breach Report (India): average breach overhead ****; non-compliance with internal policies is a contributing factor in 35% of breaches.
• Ponemon Institute: organizations with poor policy enforcement experience breach overhead 2.8× higher than those with strong compliance monitoring.
• Indian SOC 2 / ISO 27001 market: 40% of stage-1 audit failures relate to A.5.1/A.5.36 gaps, policies exist but no evidence of review or enforcement.
• Regulatory penalty growth: DPDP Act penalties can reach ****; SEBI cyber fines for intermediaries have crossed **** in multiple cases.
• Employee-driven incidents: 74% of Indian organizations report at least one insider policy violation annually, yet only 28% track remediation to closure.

Board and Investor Perspective

For boards, investors, and acquirers, A.5.36 is a governance signal. A company with beautifully written policies but no compliance monitoring is like a company with financial statements that were never reconciled, the numbers might be right, but nobody has checked.

Boards should ask management:

• How do we know our security policies are being followed?
• What is our compliance score by department and by control domain?
• How many exceptions are active, and who approved them?
• Are repeated findings indicating a systemic control weakness?
• Have we linked compliance status to executive and manager objectives?

Investors and acquirers increasingly conduct cybersecurity due diligence. A mature A.5.36 programme reduces transaction risk, accelerates due diligence, and can increase valuation. Conversely, evidence of unenforced policies is a red flag that may trigger deeper audits, indemnity clauses, or deal discounts.

In the Indian context, where DPDP Act liability attaches to the Data Fiduciary and its board, directors cannot claim ignorance of security practices. A.5.36 reviews provide the board-level assurance that reasonable safeguards are not only designed but also operating.

Scope and Applicability

What the Control Covers

A.5.36 applies to every information security requirement the organization has formally defined:

• Information security policy, the master policy approved by top management.
• Topic-specific policies, access control, acceptable use, data classification, supplier security, etc.
• Rules, specific mandatory statements such as "MFA is required for all privileged access" or "laptops must be encrypted."
• Standards, technical baselines such as minimum TLS version, approved cryptographic algorithms, baseline firewall rules, secure configuration benchmarks.
• Procedures, step-by-step processes such as onboarding, termination, incident response, change management.
• Guidelines, while guidelines are advisory, where the organization has declared them mandatory, they fall under A.5.36.

Who It Applies To

Size-Based Applicability

What Is Out of Scope

• Informal advice or unwritten expectations, A.5.36 requires documented policy/rule/standard.
• Personal conduct unrelated to information security, handled under general HR policies.
• Physical safety rules not tied to information security, covered by A.7 physical controls.
• Purely financial or operational compliance, unless linked to information security policy.

Key Definitions and Terminology

Relationship to Other Controls

A.5.36 is a cross-cutting control. It depends on other controls for the rules to exist, and it provides the enforcement loop that makes the entire ISMS credible.

Upstream Controls (Provide the Rules)

Parallel Controls (Participate in Compliance)

Downstream Controls (Depend on A.5.36)

Rationale

A.5.36 transforms the ISMS from a "paperwork exercise" into a living system. Without it, A.5.1 policies gather dust, A.6.4 disciplinary processes are never invoked, and A.8 technical controls drift out of compliance. Auditors treat A.5.36 as a litmus test for ISMS maturity.

Detailed Implementation Guidance

The Compliance Review Lifecycle

A sustainable A.5.36 programme follows a closed-loop lifecycle:

┌─────────────────────────────────────────────────────────────┐
│  1. DEFINE                                                  │
│  • Identify policies, rules, standards, and procedures      │
│  • Map each to owners, controls, and evidence sources       │
│  • Define review frequency based on risk                    │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  2. PLAN                                                    │
│  • Build annual compliance-review schedule                  │
│  • Define sampling approach and review methods              │
│  • Allocate resources and set deadlines                     │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  3. EXECUTE                                                 │
│  • Conduct reviews (manual, automated, or hybrid)           │
│  • Collect evidence and record findings                     │
│  • Classify non-compliance by severity                      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  4. REMEDIATE                                               │
│  • Assign owners and due dates                              │
│  • Apply corrective actions                                 │
│  • Involve HR/legal where disciplinary action is needed     │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  5. VERIFY & CLOSE                                          │
│  • Confirm remediation is effective                         │
│  • Update risk register if residual risk remains            │
│  • Close findings with evidence                             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  6. REPORT & IMPROVE                                        │
│  • Report to management review                              │
│  • Analyse trends and root causes                           │
│  • Update policies, training, or controls                   │
└─────────────────────────────────────────────────────────────┘

Building the Compliance Register

The compliance register is the single source of truth for A.5.36. It should contain:

Review Methods

Frequency Guidance

Non-Compliance Severity Model

Classify every finding so resources are allocated correctly:

Handling Non-Compliance

Every non-compliance must follow a consistent workflow:

1. Detect, Through review, monitoring, audit, or report.
2. Record, Log in issue tracker with evidence, date, finder, and affected policy.
3. Assess, Determine severity, scope, and root cause.
4. Assign, Allocate owner and due date for remediation.
5. Contain, If active risk, apply immediate compensating controls.
6. Remediate, Implement corrective action.
7. Verify, Confirm remediation is effective and sustained.
8. Close, Document closure with evidence.
9. Report, Include in management review and metrics.
10. Learn, Update policy, training, or automation to prevent recurrence.

Exception Management

Exceptions are not a way to ignore policy. A valid exception requires:

• Business justification
• Risk assessment
• Compensating controls
• Time-bound expiry date
• Approval by authorized person (based on risk level)
• Entry in exception register
• Review at expiry or when circumstances change

Exception approval matrix:

Integrating with HR Disciplinary Process

A.5.36 and A.6.4 are closely linked. The organization should:

• Reference information security policy compliance in the employee handbook and code of conduct.
• Train managers on how to identify and escalate security violations.
• Apply proportional discipline: coaching for first-time minor violations; written warning; termination for wilful misconduct or data theft.
• Maintain confidentiality and due process.
• Track anonymized disciplinary statistics for trend analysis.

Evidence Management

Evidence must be trustworthy:

• Stored in a tamper-evident location (GRC tool, document management system, or WORM storage).
• Version-controlled with date, owner, and review period.
• Retained for at least the certification cycle plus one year (minimum 4 years; regulated entities often need 6–8 years).
• Cross-referenced to policies and controls.
• Available to auditors without modification.

Compliance Sampling Methodology

When full population review is impractical, a documented sampling methodology ensures your A.5.36 evidence remains defensible to auditors and regulators.

Sampling Approaches

Sample Size Guidance

Documenting Sampling

For every sampled review, record:

• Population definition and size.
• Sampling method and rationale.
• Sample size and selection criteria.
• List of sampled items (or reference to selection output).
• Review results and extrapolation to population.

Auditors are more likely to accept sampling when it is risk-based, repeatable, and documented. For Critical/High-risk controls, prefer 100% review or automated continuous monitoring over sampling.

Compliance by Control Domain

A.5.36 must cover every domain where your organization has defined policy. Below are control-specific compliance checks mapped to common ISO 27001 topic areas.

Access Control (A.5.15–A.5.18, A.8.2–A.8.5)

• Verify that all user accounts are unique and attributable.
• Confirm MFA is enforced for privileged, remote, and customer-facing access.
• Sample access requests for documented approval and business justification.
• Review terminated-user access revocation against HR exit records.
• Validate quarterly access reviews are completed and signed off.

Data Protection (A.5.12–A.5.14, A.8.10–A.8.12)

• Confirm data classification labels are applied to repositories and documents.
• Verify encryption at rest for Confidential/Restricted data.
• Verify encryption in transit (TLS 1.2 minimum; TLS 1.3 preferred).
• Check DLP policies are active and generating alerts.
• Review data retention and secure disposal records.

Network and Infrastructure (A.8.20–A.8.23)

• Review firewall rule sets against the approved baseline.
• Verify network segmentation between production, development, and guest networks.
• Confirm wireless networks use enterprise authentication.
• Validate VPN is required for remote administrative access.

Secure Development (A.5.31, A.8.25–A.8.32)

• Confirm security requirements are documented for projects.
• Verify SAST/SCA/DAST tools are integrated into CI/CD.
• Scan repositories for secrets and credentials.
• Validate change approvals for production deployments.
• Check that security training is completed before production access.

Supplier Security (A.5.19–A.5.23)

• Verify security clauses exist in all high-risk supplier contracts.
• Confirm annual supplier security reviews are completed.
• Check supplier access is reviewed and least-privilege enforced.
• Validate supplier incident notification requirements.

Incident Management (A.5.24–A.5.28, A.6.8, A.8.15–A.8.17)

• Confirm incident response plan is tested annually or semi-annually.
• Verify incident logs are retained and reviewed.
• Check post-incident reviews include corrective actions.
• Validate reporting channels are known to staff.

Human Resources (A.6.1–A.6.6)

• Verify employment contracts include security clauses.
• Confirm background checks for sensitive roles.
• Validate onboarding and termination security checklists.
• Check security awareness training completion rates.

Building a Compliance-First Culture

Technology alone cannot enforce compliance. Culture determines whether people follow rules when nobody is watching.

Leadership Modelling

• Executives must complete the same training and acknowledge the same policies as staff.
• Leaders should visibly support compliance decisions, including unpopular ones like revoking legacy access.
• Board and committee meetings should discuss compliance status, not just incidents.

Positive Reinforcement

• Recognize teams and individuals with strong compliance records.
• Share anonymized success stories: "Engineering reduced secrets in code to zero."
• Make compliance metrics visible on team dashboards.

Proportional Enforcement

• Distinguish mistakes from negligence and malice.
• Use coaching and retraining for first-time minor issues.
• Reserve disciplinary action for repeated or serious violations.
• Communicate enforcement decisions fairly to maintain trust.

Psychological Safety

• Protect reporters of non-compliance from retaliation.
• Frame compliance reviews as improvement, not punishment.
• Encourage employees to suggest policy clarifications.

Integrating Compliance into Change Management

Changes are a primary source of configuration drift and policy violations. Embed compliance checks into A.8.32 change management.

Change Advisory Board (CAB) Compliance Gate

Before approving changes, the CAB should verify:

• Does the change affect a security control or policy requirement?
• Has a security impact assessment been completed?
• Are new configurations aligned with baseline standards?
• Have required approvals been obtained?
• Will the change be monitored for compliance post-implementation?

Post-Implementation Compliance Verification

Within 48–72 hours of a major change:

• Re-run configuration scans.
• Verify logs are flowing.
• Confirm access controls remain intact.
• Update compliance register if the change alters a control.

Remote and Hybrid Work Compliance

Remote work expands the attack surface and makes physical and behavioural compliance harder to observe.

Remote Work Compliance Checks

• Verify VPN/MFA usage for remote access.
• Confirm home-router security baseline where applicable.
• Check that corporate devices are enrolled in MDM and encrypted.
• Validate that sensitive documents are not printed or stored in insecure home locations.
• Confirm screen privacy and family-member access restrictions.

Monitoring Without Surveillance

• Monitor technical compliance (encryption, patch status, access logs), not personal behaviour.
• Use DLP to protect company data, not to spy on employees.
• Communicate clearly what is monitored and why.

Compliance Maturity Self-Assessment

Use the following questions to gauge your current A.5.36 maturity. Score each area from 1 (ad-hoc) to 5 (optimised).

Scoring interpretation:

• 9–45: Wide variation; focus on lowest-scoring areas first.
• Average score 1–2: Ad-hoc; build foundation urgently.
• Average score 3: Defined programme; work on automation and integration.
• Average score 4: Quantitatively managed; focus on predictive analytics and benchmarking.
• Average score 5: Optimised; maintain and share best practices.

Use the gap-analysis toolkit file to document target state and improvement actions.

Re-assess maturity every six months. The goal is not a perfect score on day one, but measurable improvement in coverage, automation, remediation speed, and cultural adoption. Use the trend to justify investment in tools, training, and headcount. A maturity score that improves over time is one of the strongest audit signals you can provide. Regular reassessment drives continuous improvement and keeps the programme aligned with evolving risks.

Tools, Technologies, and Solutions

Tool Categories for A.5.36

Vendor Comparison Matrix

Build-vs-Buy Guidance

Free / lightweight Starter Stack

• Compliance register: Google Sheets / Excel with version control in SharePoint / Google Drive.
• Technical checks: OpenSCAP, Lynis, CIS-CAT Lite.
• Cloud posture: AWS Config / Azure Policy / GCP Asset Inventory.
• Ticketing: Jira Free or GitHub Issues.
• Policy distribution: Confluence / Notion / SharePoint.
• Device compliance: Microsoft Intune (included in many M365 licences) or Scalefusion trial.

Implementation Considerations

Before purchasing or deploying A.5.36 tools, evaluate the following:

Data Residency and Sovereignty

For Indian organizations, especially BFSI, government, and healthtech, data residency is often non-negotiable. Ensure the vendor offers Indian data-centre hosting or contractual guarantees that compliance data does not leave the country. This is particularly important under DPDP Act 2023 and CERT-In directions.

Integration Architecture

A.5.36 tools should not become another silo. Prioritise integrations with:

• Identity provider (IdP) for user and access data.
• SIEM/SOAR for security event correlation.
• Ticketing system for remediation tracking.
• Cloud provider APIs for posture data.
• HR system for onboarding/termination triggers.
• Document management for evidence storage.

Tuning and False Positives

New automation tools often generate a flood of alerts. Plan a 30–60 day tuning period where security analysts review findings, adjust thresholds, and create exception workflows. Without tuning, teams ignore alerts and compliance monitoring loses credibility.

Skill Requirements

If these skills are unavailable, consider a managed service or phased rollout starting with the highest-risk areas.

Integrating Tools into the Compliance Workflow

Tools only create value when embedded into the compliance lifecycle:

1. Define control checks in the GRC tool and map them to policies and risks.
2. Configure automated tools to produce evidence that matches each check.
3. Push findings into a ticketing system with severity, owner, and SLA.
4. Use dashboards to monitor open findings, overdue items, and trends.
5. Archive evidence in the document repository with version control.
6. Report metrics to management review quarterly and annually.

Avoid the trap of buying tools and then manually copying data into spreadsheets. Automation should reduce manual effort, not increase it.

Policy and Procedure Templates

Information Security Compliance Policy (Extract)

INFORMATION SECURITY COMPLIANCE POLICY
[Organization Name]
Version: 1.0
Approved by: [CISO / CEO]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

1. PURPOSE
This policy establishes the framework for reviewing and enforcing compliance
with the organization's information security policies, topic-specific policies,
rules, standards, and procedures.

2. SCOPE
This policy applies to all employees, contractors, temporary staff, suppliers,
and third parties who access, process, store, or transmit [Organization Name]
information assets.

3. POLICY STATEMENTS
3.1 Compliance with information security policies, rules, and standards is
    mandatory for all personnel.
3.2 Compliance reviews shall be performed at planned intervals and when
    significant changes occur.
3.3 Non-compliance shall be recorded, investigated, remediated, and reported.
3.4 Repeated or wilful non-compliance may result in disciplinary action.
3.5 Exceptions to policy requirements must be documented, risk-assessed,
    approved, and time-bound.
3.6 Evidence of compliance reviews shall be retained for [X] years.

4. REVIEW FREQUENCY
4.1 Master information security policy: annually
4.2 Topic-specific policies: annually or on significant change
4.3 Technical configuration standards: monthly / continuous
4.4 Access control rules: quarterly
4.5 Supplier security obligations: annually (high-risk quarterly)

5. ROLES AND RESPONSIBILITIES
5.1 CISO: Own the compliance programme, report to management review.
5.2 Department Heads: Ensure team compliance and escalate violations.
5.3 HR: Maintain disciplinary process and support investigations.
5.4 IT / Operations: Execute automated technical compliance checks.
5.5 All Employees: Comply with policies and report non-compliance.

6. NON-COMPLIANCE HANDLING
6.1 Findings are logged in the compliance issue register.
6.2 Severity is assessed as Critical, High, Medium, Low, or Observation.
6.3 Owners and due dates are assigned.
6.4 Corrective actions are verified before closure.
6.5 Disciplinary action is applied in accordance with HR policy.

7. EXCEPTIONS
7.1 Exceptions require documented justification and risk acceptance.
7.2 Low-risk exceptions: approved by Control Owner.
7.3 Medium-risk exceptions: approved by CISO.
7.4 High/Critical exceptions: approved by Risk Committee / CEO.

8. REPORTING
8.1 Compliance status is reported quarterly to the Information Security
    Committee and annually to top management.
8.2 Critical non-compliances are escalated immediately.

9. REVIEW
This policy is reviewed annually and when significant changes occur.

Compliance Review Procedure (Extract)

PROCEDURE: INFORMATION SECURITY COMPLIANCE REVIEW
Reference: A.5.36
Owner: CISO
Frequency: Quarterly + event-triggered

1. PREPARATION
   1.1 Review the compliance register and identify reviews due this quarter.
   1.2 Notify policy owners and technical teams of upcoming reviews.
   1.3 Gather required evidence: logs, scan reports, access lists, policy
       versions, training records.

2. EXECUTION
   2.1 Perform automated technical scans for configuration standards.
   2.2 Conduct manual checks using the approved checklist.
   2.3 Interview sample personnel where behavioural compliance is assessed.
   2.4 Review exception register for expired or unreviewed exceptions.

3. FINDINGS
   3.1 Record each finding in the issue tracker with:
       - Policy / rule / standard reference
       - Description and evidence
       - Severity
       - Affected area and owner
   3.2 Validate false positives before logging.

4. REMEDIATION
   4.1 Assign owner and due date.
   4.2 For Critical/High findings, apply immediate containment.
   4.3 Track remediation to closure.
   4.4 Verify effectiveness through re-test or evidence review.

5. REPORTING
   5.1 Compile quarterly compliance report.
   5.2 Present to Information Security Committee.
   5.3 Include summary in management review input.

6. CONTINUOUS IMPROVEMENT
   6.1 Analyse trends and recurring findings.
   6.2 Update policies, training, or automation as needed.

Exception Request Template

Risk Assessment and Treatment

Risk Scenario Table

Risk Treatment Plan Summary

• Mitigate: Implement compliance-review programme, automation, training, and exception management.
• Transfer: Cyber insurance for residual regulatory and breach overhead.
• Accept: Low-severity, low-likelihood residual risks documented with management approval.
• Avoid: Discontinue high-risk practices that cannot be brought into compliance.

Audit and Compliance Checklist

Auditor Questions with Expected Evidence

Pre-Audit Self-Check

• Compliance policy approved and published.
• Compliance register current and complete.
• Last 4 quarters of review records available.
• All Critical/High findings closed or risk-accepted.
• Exception register reviewed for expired items.
• Management review includes compliance status.
• Training records show policy awareness.
• Automated tool outputs saved as evidence.
• Disciplinary process references security policy.
• Supplier compliance reviews performed.

Metrics and KPIs

Recommended Compliance Metrics

Dashboard Layout

┌──────────────────────────────────────────────────────────────┐
│  COMPLIANCE DASHBOARD — Q2 2026                              │
├──────────────────────────────────────────────────────────────┤
│  Overall Compliance Score: 87%                               │
│  ████████████████████████████████░░░░                        │
├──────────────────────────────────────────────────────────────┤
│  Reviews Due: 24    Completed: 22 (92%)    Overdue: 2        │
│  Critical Findings: 1    High: 3    Medium: 8    Low: 12     │
│  Overdue Critical/High: 0                                    │
├──────────────────────────────────────────────────────────────┤
│  Top Non-Compliance Areas                                    │
│  1. MFA not enabled on 6 admin accounts (Critical)           │
│  2. Patch compliance 82% on Windows servers (High)           │
│  3. Clean-desk violations in 3 departments (Medium)          │
├──────────────────────────────────────────────────────────────┤
│  Active Exceptions: 7    Expiring This Month: 2              │
│  Policy Acknowledgment: 99%    Training: 96%                 │
└──────────────────────────────────────────────────────────────┘

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian NBFC, From Audit Failure to Clean ISO 27001 Certification

Organization: A mid-sized NBFC in Mumbai with 800 employees, offering personal and business loans.

Challenge: The NBFC had invested heavily in drafting 22 information security policies and had implemented a core banking system, firewall, and antivirus. However, during its first ISO 27001 stage-2 audit, the auditor raised four major non-conformities under A.5.36:

1. No evidence that topic-specific policies were reviewed for compliance.
2. The Access Control Policy required quarterly access reviews, but only one review had been performed in 18 months.
3. Multiple expired exceptions allowed legacy integrations without MFA.
4. Several branch managers could not explain how they checked compliance in their branches.

The audit was suspended, and the NBFC risked losing enterprise partnerships.

Solution: Singahi designed a 90-day A.5.36 remediation programme:

• Compliance Register: Mapped all 22 policies to 68 specific checks, owners, methods, and frequencies.
• Automation: Deployed a configuration audit tool to verify Windows baseline, firewall rules, and privileged account MFA weekly.
• Branch Compliance Kit: Provided branch managers with a monthly 15-point checklist covering clean desk, visitor logs, access cards, and password hygiene.
• Exception Clean-Up: Reviewed all 14 exceptions; closed 9, renewed 4 with compensating controls, and escalated 1 to the board.
• Management Rhythm: Established a monthly Information Security Committee meeting and quarterly board report on compliance status.
• HR Integration: Updated the code of conduct to explicitly reference information security policy compliance and trained all managers.

Results:

• Re-audit passed with zero major non-conformities.
• Achieved ISO 27001:2022 certification within 4 months.
• Access review completion improved from 12% to 100%.
• Critical findings reduced from 18 to 2 per quarter.
• RBI cyber-security inspection rated the NBFC "satisfactory."

Illustrative Scenario 2: Indian Healthtech SaaS, Preventing a Breach Through Compliance Monitoring

Organization: A Bangalore-based healthtech SaaS provider with 220 employees, processing personal health data for hospitals and clinics.

Challenge: The company had a documented Secure Development Policy and Data Classification Policy. However, a routine compliance review (the first in 12 months) discovered:

• 34 production API keys and database credentials stored in private GitHub repositories.
• 12 developers had not completed secure-coding training despite policy requiring it before production access.
• The Data Classification Policy required encryption of "Restricted" data, but 6 S3 buckets containing patient reports were publicly readable.
• No supplier security reviews had been performed for 3 critical cloud vendors.

The company was 60 days from a SOC 2 Type II audit and risked a DPDP Act violation.

Solution: Singahi implemented a continuous compliance-monitoring programme:

• Secret Scanning: Integrated GitHub Advanced Security and TruffleHog into CI/CD; blocked commits with secrets and scanned all historical repositories.
• CSPM: Deployed a Cloud Security Posture Management tool to enforce S3 encryption and public-access blocks.
• Training Gate: Linked production access in the identity system to completion of role-specific secure-coding training.
• Supplier Reviews: Conducted security questionnaires and evidence reviews for the 3 critical vendors; one vendor was replaced, two signed remediation plans.
• Compliance Dashboard: Built a real-time dashboard showing policy compliance by team, with weekly leadership reviews.
• DPDP Readiness: Mapped compliance checks to DPDP Act obligations and added data-principle rights verification to the review cycle.

Results:

• Zero critical findings in the SOC 2 Type II audit.
• Secrets in repositories reduced to zero within 30 days.
• Public S3 buckets eliminated; encryption enforced at 100%.
• Training completion reached 98%.
• The company successfully positioned its compliance monitoring as a competitive differentiator in hospital RFPs.

Multi-Framework Mapping

Mapping Commentary

• SOC 2: A.5.36 directly supports COSO monitoring activities and the common criteria for communication, monitoring, and system operations.
• PCI DSS: Requirements in section 12 expect policy maintenance, monitoring, and review, A.5.36 supplies the mechanism.
• NIST 800-53: CA-7 (Continuous Monitoring) and PM-10 are the closest mappings; A.5.36 operationalises these controls.
• CIS Controls: Secure configuration, data protection, and audit-log management all require compliance verification.
• COBIT: MEA01 is essentially the governance expression of A.5.36.
• GDPR / DPDP Act 2023: Both frameworks require organisations to demonstrate compliance; A.5.36 reviews produce the evidence.

Implementation Roadmap

Phase-Based Roadmap

12-Week Detailed Plan

Week 1:

• Form compliance-review working group (CISO, Legal, HR, IT, Operations).
• Gather all current policies, standards, and procedures.
• Define risk-based review frequencies.

Week 2:

• Build policy-to-control mapping matrix.
• Identify evidence sources for each check.
• Draft compliance policy and procedure.

Week 3:

• Create compliance register in GRC tool or spreadsheet.
• Assign owners and due dates.
• Baseline current compliance state.

Week 4:

• Conduct first round of manual reviews.
• Run technical baseline scans.
• Log findings and assign severities.

Week 5:

• Evaluate and procure automation tools.
• Configure first automated checks (MFA, patch, encryption).

Week 6:

• Integrate automated findings into ticketing.
• Tune alert thresholds to reduce noise.

Week 7:

• Expand automation to cloud posture and device compliance.
• Validate scan results against manual samples.

Week 8:

• Train managers on compliance responsibilities.
• Update HR disciplinary process.

Week 9:

• Run exception clean-up exercise.
• Enforce time-bound approvals.

Week 10:

• Verify closure of pilot findings.
• Refine remediation workflow.

Week 11:

• Compile first quarterly compliance report.
• Prepare management-review presentation.

Week 12:

• Present to Information Security Committee and top management.
• Document lessons learned and update roadmap.

Critical Success Factors

Based on Singahi's experience across 50+ certifications, the following factors determine whether an A.5.36 programme succeeds or becomes a documentation exercise:

Executive Sponsorship

Compliance monitoring requires authority to ask tough questions and enforce unpopular decisions. Without visible executive sponsorship, findings get buried, exceptions become permanent, and the programme loses credibility. Ensure the CISO or equivalent has direct access to the CEO or board for Critical/High escalations.

Start with High-Risk Areas

Do not try to monitor every policy perfectly from day one. Prioritise areas with the highest risk and audit visibility:

• Access control and MFA.
• Patch and vulnerability management.
• Cloud configuration compliance.
• Supplier security for critical vendors.

Early wins in these areas build confidence and demonstrate value.

Make Compliance Everyone's Job

A common failure mode is making compliance a "security team job." Department heads must own team-level compliance, IT must own technical checks, HR must own discipline, and Legal must own regulatory alignment. Use the RACI matrix to make ownership explicit.

Automate Early, But Validate

Automation scales compliance monitoring, but only if outputs are trusted. Always validate automated findings with manual samples during the tuning phase. Untrusted automation leads to alert fatigue and ignored findings.

Close the Loop

Every finding must have an owner, due date, verification, and closure evidence. A finding that is "logged but not closed" is worse than no finding at all because it proves the organization knows about a problem and has not fixed it.

Communicate Transparently

Share compliance status, trends, and improvement actions with employees. When people understand why policies exist and see that violations are addressed fairly, compliance becomes part of the culture rather than a checkbox.

FAQ

Q1: Is A.5.36 the same as internal audit?

No. A.5.36 is the operational compliance-review process owned by management. Internal audit (A.5.35) is an independent assurance activity. A.5.36 should happen continuously; A.5.35 is periodic and independent.

Q2: How often must compliance be reviewed?

There is no fixed interval in ISO 27001. The frequency must be "planned" and based on risk. Most organizations review technical controls monthly or continuously, access controls quarterly, and policies annually. Significant changes trigger additional reviews.

Q3: Do we need automated tools to pass audit?

Not strictly, but auditors expect automation for technical controls in all but the smallest organizations. Manual checks alone for 500+ endpoints will raise doubts about coverage and reliability.

Q4: What counts as "significant change" requiring a review?

Examples include mergers or acquisitions, launch of a new product, migration to cloud, new regulation, major security incident, changes to the ISMS scope, or substantial restructuring.

Q5: Can a department head approve their own exceptions?

Only for low-risk exceptions. Medium and high-risk exceptions require CISO or higher approval. Critical exceptions should go to the risk committee or board.

Q6: How do we handle non-compliance by senior management?

Senior leaders must be held to the same or higher standard. Escalate through the board or audit committee. A policy that leadership ignores will rapidly undermine the entire ISMS.

Q7: What evidence should we retain?

Retain review schedules, checklists, scan reports, attestation forms, finding logs, corrective-action evidence, exception registers, management-review minutes, and training records. Minimum 4 years; regulated sectors 6–8 years.

Q8: How do we prove compliance without over-documenting?

Use a risk-based approach. Automate evidence collection where possible. Keep a single compliance register that links to underlying evidence rather than duplicating everything.

Q9: Should supplier compliance be included in A.5.36?

Yes. Supplier obligations are part of your security framework. Review supplier compliance at least annually, more frequently for high-risk suppliers.

Q10: How does A.5.36 relate to DPDP Act 2023?

DPDP Act Section 8 requires Data Fiduciaries to implement reasonable safeguards. A.5.36 reviews of access control, data classification, encryption, and training provide direct evidence that safeguards are operating.

Q11: Who should own A.5.36 in a small organization without a CISO?

The most senior person responsible for information security, often the IT Manager or CTO, should own A.5.36. HR and Legal should support disciplinary and regulatory aspects. As the organization grows, a dedicated CISO or Compliance Manager should take over.

Q12: Can we use internal audit as the compliance-review function?

Internal audit (A.5.35) provides independent assurance and should not be the primary operational compliance-review function. Management must demonstrate its own compliance-monitoring activities. Internal audit can then independently evaluate whether those activities are effective.

Q13: How do we balance automation with privacy and employee trust?

Automate technical controls (configurations, patches, encryption status) and use monitoring for security purposes only. Be transparent about what is monitored. Avoid surveillance of personal communications or behaviour unrelated to security. Document monitoring scope in the Acceptable Use Policy and Privacy Notice.

Q14: What is the minimum evidence needed for A.5.36?

At minimum, maintain: a compliance register, a review schedule, evidence that reviews were performed, a non-compliance log with corrective actions, exception register, and management-review inputs. The more mature your organization, the more automated and granular your evidence should be.

Q15: How do we handle a policy that everyone is violating because it is impractical?

This signals a policy or control failure, not a workforce failure. Analyse root causes: is the policy unclear, is training inadequate, is the control too burdensome, or is tooling missing? Revise the policy, improve controls, retrain, and then re-verify compliance. Do not simply ignore widespread non-compliance.

Q16: Should we review compliance with guidelines or only mandatory policies?

A.5.36 applies to policies, rules, and standards. Guidelines are typically advisory, so they do not require the same enforcement. However, if your organization has declared a guideline mandatory or if auditors/customers expect adherence, include it in your compliance register.

Q17: How do we demonstrate A.5.36 compliance to customers?

Provide a summary compliance report (sanitized of sensitive findings), evidence that reviews are scheduled and performed, and metrics such as review coverage, finding closure rates, and exception counts. Many enterprise customers will ask for this during vendor security assessments.

Q18: What is the relationship between A.5.36 and management review?

A.5.36 produces inputs for management review (Clause 9.3). The compliance report should inform top management about whether the ISMS is effective, where risks are emerging, and what resources or decisions are needed. Without this link, A.5.36 is isolated from governance.

References and Further Reading

Standards

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements
• ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls
• ISO/IEC 27003:2017, Information security management system implementation guidance
• ISO 15489, Information and documentation, Records management

Indian Regulations

• Digital Personal Data Protection Act, 2023
• Information Technology Act, 2000 and Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011
• CERT-In Directions, 2022
• Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector; Cyber Security Framework in Banks
• Securities and Exchange Board of India, Cyber Security and Cyber Resilience Framework
• Insurance Regulatory and Development Authority of India, Cyber Security Guidelines
• Companies Act, 2013

Frameworks

• NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
• CIS Controls v8, Centre for Internet Security
• COBIT 2019, ISACA
• SOC 2 Trust Services Criteria, AICPA
• PCI DSS v4.0, PCI Security Standards Council

Additional Resources

• CIS Benchmarks, https://www.cisecurity.org/cis-benchmarks
• NIST Cybersecurity Framework
• OWASP Top 10 and OWASP ASVS
• Singahi ISO 27001 Blog, /

Recommended Further Reading

For organizations serious about A.5.36 maturity, the following resources provide deeper guidance:

• ISO/IEC 27007:2020, Guidelines for information security management systems auditing. Useful for aligning internal audit and compliance-review activities.
• ISO/IEC 27008:2022, Guidance for the assessment of information security controls. Directly supports the technical assessment aspect of A.5.36.
• NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. Excellent for organizations building continuous compliance monitoring.
• NIST SP 800-53A Rev 5, Assessing Security and Privacy Controls in Federal Information Systems and Organizations. Provides assessment procedures that can be adapted to ISO 27001.
• CSA Cloud Controls Matrix (CCM), For cloud-native organizations mapping compliance checks to cloud security domains.
• ISACA Compliance Principles, Guidance on designing and operating compliance programmes within the COBIT framework.
• India's DPDP Act 2023 Draft Rules, Once notified, these rules will specify operational requirements for reasonable safeguards and compliance evidence.
• RBI's Master Direction on Information Technology Framework for the NBFC Sector and Cyber Security Framework in Banks, Essential for financial services compliance reviewers.
• SEBI Master Circular on Cyber Security and Cyber Resilience, Required reading for market intermediaries and listed companies.

How to Stay Current

• Subscribe to ISO updates through your national standards body (BIS in India).
• Monitor CERT-In advisories and directions.
• Follow RBI, SEBI, and IRDAI circulars relevant to your sector.
• Review customer security questionnaires annually, they often reveal emerging compliance expectations.
• Attend industry forums such as ISACA chapters, DSCI events, and OWASP meetups in India.

End of guide.