Security teams generally build logging for distinct objectives. One for the ISO 27001 certification audit. Again, when RBI or SEBI asks for evidence. A third when a customer contract demands PCI DSS alignment (Now there is a new addition: when the DPDP Act deadline arrives).
Each project gets its own tool, retention rule and owner.
In this blog, we recommend a better order of operations. A logging solution as per ISO 27001 gives you a base layer that satisfies most of what every other framework asks for. Build it properly and the rest becomes mapping work.
We will cover what ISO 27001 requires under Annex A 8.15, 8.16 and 8.17, how those controls map to Indian regulatory obligations and also the four gaps ISO alone will not close.
What ISO 27001 requires for logging
The 2022 revision split the old 12.4 clause into separate controls. It separates collecting logs from reading them.
8.15 Logging: produce, protect and analyse
Annex A 8.15 requires you to produce logs recording activities, exceptions, faults and other relevant events, then store, protect and analyse them. The standard does not ask you to log everything, only relevant events. Getting that wrong costs you either way – over-logging inflates storage, under-logging leaves blind spots your assessor will find.
Each record needs the user identity, the activity, the timestamp, the system involved and the relevant network addresses. A log line without a user ID is not evidence.
8.16 Monitoring activities: the control most teams skip
Annex A 8.16 is new in the 2022 version and it is where certifications quietly fail. It requires networks, systems and applications to be monitored for anomalous behaviour, with action taken to evaluate potential incidents. 8.15 records history. 8.16 analyses the present. You can have logging without monitoring, and plenty of organisations do.
Auditors test this by asking for review records. Proof that a named person looked at the logs on a defined cadence and acted on what they found. Perfect collection with no documented review gets written up.
8.17 Clock synchronisation: the quiet dependency
Without consistent time across log sources, correlation fails. Your firewall says 14:02, your application says 14:07 and your incident timeline falls apart. Network Time Protocol synchronisation is small work with outsized consequences. Fix it first.
Why ISO 27001 works as your base layer
The controls are outcome-based
ISO tells you what logging has to achieve, not which product to buy or how many days to retain. That vagueness is what makes the layer portable – you define scope once at a level that clears the highest bar you face, then reuse it.
Certification forces the documentation others assume
RBI, SEBI and IRDAI all expect board-approved policies, defined retention and evidence of review. ISO 27001 makes you produce these artefacts and keeps you producing them through surveillance audits. That same evidence pack is what the other regulators ask for.
Mapping the base layer to Indian regulations
Every framework below asks for the same five things ISO already gave you — collection from in-scope systems, attributable records, protected storage, documented review and retrievable evidence. Each adds a scope rule, a storage rule or a clock.
| Framework | What your ISO layer already delivers | What you add on top |
| DPDP Act 2023 | Access records with user attribution and timestamps, protected storage, review process | Scope narrowed to personal data systems, one-year access log retention under Rule 6, breach detection evidence |
| RBI Master Directions | Audit trail mechanics, retention policy, monitoring cadence | Non-repudiation-grade detail, privileged user logging, six-hour DAKSH reporting, data residency in India |
| SEBI CSCRF | Collection, normalisation, correlation, documented review | Tamper-proof write-once storage, obligations scaled by entity tier, SOC integration at higher tiers |
| PCI DSS | Log content fields, daily review discipline, log protection | A named list of mandatory events, 12-month retention with 3 months immediately available, scoping to the cardholder data environment |
| IRDAI | Policy, ownership, review evidence, retention schedule | Insurer-specific core and policyholder system coverage, board-level reporting |
The deltas are scope and storage
Read the right-hand column again. Almost nothing there is a new pipeline. It is the same ingestion, normalisation and correlation engine, pointed at different systems or held to a stricter storage rule.
That is why sequencing matters. Build DPDP logging first and you get a personal-data-shaped system that will not stretch to RBI’s forensic needs. Build the ISO layer first and every later scope carves out of it.
We cover each framework separately in our guides to logging under the DPDP Act 2023, logging as per SEBI CSCRF and logging as per IRDAI guidelines.
Certification produces the paperwork the others assume
RBI, SEBI and IRDAI all expect board-approved policies, a defined retention period and evidence of review. They assume these exist. ISO 27001 makes you produce them and keeps producing them through surveillance audits, so your certification evidence pack is the same one RBI Master Direction compliance will ask for.
Build to the strictest column
Take the most demanding value in each row and make it your default. Write-once storage from CSCRF. Longest retention from PCI DSS. Residency from RBI. This costs marginally more on day one and saves an entire re-architecture the first time a new obligation lands.
Four gaps ISO 27001 will not close
ISO gets you most of the way, not all of it.
- No fixed retention period. ISO leaves duration to your risk assessment. Indian regulators and the IT Act 2000 point to longer minimums than most teams pick.
- No tamper-proof storage mandate. ISO asks you to protect logs. SEBI CSCRF expects write-once or append-only storage.
- No data residency rule. ISO is silent on where logs live. RBI and SEBI are not.
- No incident reporting clock. CERT-In and RBI both work on six hours from detection.
How to build the layer once
Start with an asset inventory mapped to confirmed, active log sources — not what your CMDB thinks is accurate. Then build five capabilities:
- Ingestion from all in-scope systems in near real time
- Normalisation into a consistent, searchable schema
- Centralised storage that is tamper-evident, retained to your longest applicable obligation
- Correlation and detection so 8.16 monitoring runs continuously
- Reporting that produces assessor-ready evidence without a custom export project
A SIEM platform delivers all five. If you already run full stack observability, extending it to security events is a much shorter journey than starting over.
Conclusion
Scope your ISO logging layer to the strictest obligation you face, not the easiest. Treat 8.16 monitoring as a documented recurring activity with named owners. Design retention and residency for your regulators, because ISO will not tell you when you have got them wrong.
At CyberNX, we build single logging architectures that carry ISO 27001 certification and Indian regulatory obligations together. We combine ISO 27001 consulting with full stack observability solutions so you build once and certify many times. Talk to our team about mapping your logging setup against every framework you answer to.
Logging solution as per ISO 27001 FAQs
What is the log retention period under ISO 27001?
ISO 27001 does not specify one. Retention follows your risk assessment, business needs and legal requirements. In India most organisations align to the IT Act 2000 minimum of two years. Whatever you choose must be documented and approved – an undocumented period is a finding in itself.
Is a SIEM mandatory for ISO 27001 certification?
No. ISO 27001 is technology-neutral, and a smaller organisation can satisfy 8.15 and 8.16 with lighter tooling and disciplined manual review. Once you also answer to RBI, SEBI or PCI DSS, the correlation and evidence demands make a SIEM the practical choice.
What is the difference between Annex A 8.15 and 8.16?
8.15 covers logging – producing, storing, protecting and analysing records. 8.16 covers monitoring – actively watching for anomalous behaviour and acting on it. Organisations commonly implement 8.15 well and neglect 8.16, which is the more frequent source of non-conformities.
