PFRDA Cyber Security & IS Audit

Introduction to the PFRDA Cyber Security & IS Audit Framework

The Pension Fund Regulatory and Development Authority (PFRDA) is the statutory regulator constituted under the PFRDA Act, 2013, charged with promoting old-age income security and regulating the National Pension System (NPS) and the Atal Pension Yojana (APY). As the pension ecosystem has digitised, PFRDA has progressively hardened its expectations around information security, cyber resilience and technology governance for every intermediary that touches subscriber data or contributions. This guide is an auditor-grade deep-dive into the PFRDA Cyber Security & IS Audit framework as expressed through PFRDA's cyber security guidelines, the Central Recordkeeping Agency (CRA) technology standards, and the periodic Information Systems (IS) Audit and Cyber Security Audit obligations imposed on intermediaries such as Points of Presence (PoP), Pension Funds (PFs), Custodians, the Trustee Bank, Annuity Service Providers (ASPs) and the CRAs.

Unlike a single monolithic standard, PFRDA's cyber posture is a layered construct: it draws on RBI's cyber security frameworks (given many intermediaries are banks or NBFCs), SEBI's cyber security and cyber resilience framework (given overlaps with market intermediaries), CERT-In directions of 28 April 2022 on incident reporting and log retention, the DPDP Act 2023 for personal data, and PFRDA's own circulars mandating annual IS audits and vulnerability assessments. This page treats the framework as a consolidated control set that a CERT-In empanelled auditor would test in the field, and gives implementers a concrete build-and-remediate roadmap.

What is PFRDA Cyber Security & IS Audit?

PFRDA Cyber Security & IS Audit is the composite set of information-security, cyber-resilience and technology-governance requirements that PFRDA imposes on NPS/APY intermediaries, verified through an independent, periodic audit conducted by a CERT-In empanelled auditor or a qualified IS audit firm. The audit tests whether the intermediary's systems that store, process or transmit subscriber data, PRAN (Permanent Retirement Account Number) records, contribution flows and scheme information are governed, protected, monitored and recoverable to the standard PFRDA expects.

The framework has three intertwined objectives. First, confidentiality and integrity of subscriber and scheme data, including PRAN, nominee, KYC, bank and contribution records. Second, availability and resilience of NPS transaction processing, so that contributions, withdrawals, exits and annuity issuance are not disrupted. Third, accountability and auditability, so that PFRDA and the NPS Trust can obtain assurance that intermediaries meet their technology and cyber obligations on a continuing basis.

In practice the framework manifests as: (a) a board/senior-management approved information security and cyber security policy; (b) technical controls across network, application, endpoint, data and identity layers; (c) continuous monitoring including a SOC and log retention; (d) periodic Vulnerability Assessment and Penetration Testing (VAPT); (e) an annual IS Audit and a Cyber Security Audit; and (f) incident response and reporting aligned to CERT-In and PFRDA timelines. The IS Audit component specifically evaluates IT general controls (ITGC), application controls, change management, data centre operations and business continuity.

Who must comply?

The obligation attaches to every regulated intermediary within the NPS/APY architecture, scaled by the criticality and volume of subscriber data and transactions each handles. The following entities are typically in scope.

• Entities registered or empanelled with PFRDA under NPS/APY regulations, irrespective of whether they are also RBI-, SEBI- or IRDAI-regulated.
• Material outsourced/technology service providers and cloud vendors supporting in-scope systems (via contractual flow-down and right-to-audit).
• Any subsidiary, branch or gateway that processes PRAN, contribution, nominee, KYC or bank-mandate data on behalf of an intermediary.

Structure of the PFRDA Cyber Security & IS Audit framework

The framework can be decomposed into governance, technical and assurance control domains. The table below sets out the domains an auditor tests, the indicative control families within each, and the primary regulatory anchor. Identifiers (e.g. GOV-1) are CyberSigma working references used consistently across this guide's checklist; they are not official PFRDA control numbers.

Master assessment checklist

This is the operative section for both auditors and implementers. Each control family below is enumerated with a h3 heading and a table mapping what an auditor verifies against the typical evidence an intermediary must produce. No domain is skipped. Implementers should read the 'What to verify' column as a build requirement and the 'Typical evidence' column as the artefact to maintain.

GOV — Governance & Policy

IAM — Identity & Access Management

NET — Network Security

APP — Application & Secure Development

DAT — Data Protection & Privacy

END — Endpoint & Server Security

VTM — Vulnerability & Threat Management

MON — Security Monitoring & SOC

IR — Incident Response & Reporting

BCP — Business Continuity & Disaster Recovery

TPR — Third-Party & Cloud Risk

AUD — IS Audit & Assurance

Scoping the assessment

Scoping determines which systems, data, locations, people and third parties fall within the PFRDA cyber and IS audit. A defensible scope starts from the data: every system that stores, processes or transmits PRAN, KYC, nominee, bank-mandate or contribution data is in scope, together with the systems that secure or administer them.

• In scope: NPS/APY production applications, CRA-interfacing systems, eNPS web/mobile platforms, subscriber and contribution databases, payment and settlement interfaces, and the identity, logging and security infrastructure that supports them.
• In scope: data centres and DR sites, cloud tenancies hosting in-scope workloads, and the network paths connecting subscribers, PoPs and the CRA.
• In scope: privileged administrators, developers with production access, and outsourced/managed service providers touching in-scope systems.
• Scope reduction: strong segmentation, tokenisation of identifiers and isolation of non-NPS corporate systems can legitimately reduce scope, provided the isolation is evidenced and tested.
• Out of scope only where demonstrably isolated: general corporate IT with no path to NPS data. This must be justified in writing and validated by the auditor.
• Time boundary: define the audit period (typically the preceding financial year) and the point-in-time configuration review date.

Implementation approach

A phased programme moves an intermediary from an unstructured state to a defensible, audit-ready posture. Each phase below lists the core activities and the deliverables an auditor will later expect to see.

Phase 1 — Discover & Baseline (Weeks 1-4)

• Activities: establish governance sponsorship; inventory in-scope systems, data flows and third parties; map applicable circulars (PFRDA, RBI, SEBI, CERT-In, DPDP); perform a gap assessment against the domains in this guide.
• Deliverables: asset and data-flow inventory, applicability/regulatory-mapping matrix, gap-assessment report with prioritised findings, project charter.

Phase 2 — Design & Policy (Weeks 4-8)

• Activities: draft/refresh the cyber security policy, standards and procedures; define RACI and the CISO mandate; design target-state architecture for segmentation, IAM, logging and encryption; establish the CCMP and IR plan.
• Deliverables: board-approved policy suite, RACI matrix, target-state architecture, CCMP, incident response plan and playbooks.

Phase 3 — Build & Remediate (Weeks 8-20)

• Activities: implement MFA and PAM; deploy/tune SIEM and EDR; enforce encryption and DLP; harden systems; remediate open VAPT findings; segment networks; operationalise change management and JML.
• Deliverables: hardened baselines, deployed control tooling with coverage evidence, remediated VAPT report, updated network architecture, change-management records.

Phase 4 — Operate & Monitor (Weeks 16-24, ongoing)

• Activities: run the SOC with defined use cases; perform access recertification; execute DR drills; conduct threat intelligence and patch cycles; track KPIs to the board.
• Deliverables: SOC runbooks and metrics, access-review records, DR drill reports, patch-compliance dashboards, board MIS.

Phase 5 — Assure & Certify (Weeks 24-28)

• Activities: engage a CERT-In empanelled auditor; conduct the IS Audit and Cyber Security Audit; validate remediation; prepare PFRDA-facing assurance.
• Deliverables: IS audit report, cyber audit report, closed-findings tracker, board sign-off, PFRDA submission pack.

Maturity / capability model

CyberSigma scores each domain against a five-level capability model so that the intermediary and PFRDA can see trajectory, not just a pass/fail snapshot. The target for a regulated NPS intermediary is Level 4 (Managed) or higher on all critical domains.

Assessment and audit approach

The audit follows a structured methodology so findings are repeatable and defensible before PFRDA.

1. Engagement setup: agree scope, audit period, criteria (this domain set plus applicable circulars), and access; confirm auditor independence and CERT-In empanelment.
2. Documentation review: examine policies, network diagrams, prior VAPT/IS audit reports, incident logs and risk registers.
3. Interviews and walkthroughs: interview the CISO, IT operations, application, DR and vendor-management owners to understand design intent.
4. Configuration and technical testing: sample-review firewall, IAM, encryption, logging and hardening configurations against baselines.
5. Vulnerability assessment and penetration testing: conduct or validate VAPT across external, internal, application, API and mobile surfaces.
6. Control operating-effectiveness testing: sample transactions, access provisioning, change tickets, backups and DR drills across the period.
7. Evidence evaluation and gap analysis: rate each control by design and operating effectiveness; classify gaps by risk.
8. Reporting: issue a draft report with findings, risk ratings and recommendations; obtain management responses and target dates.
9. Remediation and re-test: validate closure of high/critical findings; update the tracker.
10. Final report and board/PFRDA reporting: issue signed IS and cyber audit reports and support PFRDA submission.

Evidence request list

Assemble the following categorised artefacts before fieldwork to compress the audit timeline.

• Governance: cyber security policy, risk assessment, board/IT-committee minutes, CISO appointment, CCMP.
• Identity: user access lists, role matrices, PAM configuration, JML records, access-review reports, MFA policy.
• Network: architecture diagrams, firewall rule bases and reviews, IDS/IPS and DDoS configurations, VPN policy.
• Application: SDLC standard, SAST/DAST reports, code-review evidence, API security configuration, application-control matrices.
• Data: data classification and inventory, encryption and key-management config, DLP policy, DPDP consent and privacy records.
• Endpoint/Server: hardening baselines, EDR coverage, patch-compliance dashboards, configuration-management records.
• Vulnerability: VAPT reports and scope, scan schedules, remediation trackers, empanelment proof.
• Monitoring: SIEM log-source inventory, retention configuration, SOC runbooks, alert samples and metrics.
• Incident: IR plan and playbooks, incident register, CERT-In and PFRDA reporting records, PIR reports.
• Continuity: BIA, DR architecture, DR drill reports, backup and restore-test logs, BCP document.
• Third party: vendor due-diligence, contracts with audit rights, DPAs, SOC 2/ISO certificates, outsourcing register.
• Assurance: prior IS and cyber audit reports, change-management records, findings trackers, board reporting.

Roles and responsibilities

KPIs to track

• Percentage of critical/high VAPT findings closed within SLA.
• Mean time to detect (MTTD) and mean time to respond (MTTR) to security incidents.
• Patch-compliance rate for critical vulnerabilities across servers and endpoints.
• MFA and PAM coverage across privileged and remote accounts.
• Access-review completion rate and orphaned/stale account count.
• Percentage of critical log sources onboarded to SIEM with retention meeting 180 days.
• DR drill success rate and achieved RTO/RPO versus target.
• Number of overdue audit findings and average age of open findings.
• CERT-In and PFRDA incident-reporting timeliness (within mandated windows).
• Percentage of material vendors with current security due diligence and DPAs.

Readiness checklist

• Board-approved cyber security policy in force and reviewed within 12 months.
• CISO/security officer appointed with a defined mandate and RACI.
• Complete asset and data-flow inventory covering all NPS/APY systems.
• MFA enforced on all privileged, remote and administrative access.
• Privileged Access Management with session recording operational.
• Network segmentation isolating NPS production from corporate zones.
• Encryption at rest and in transit for all subscriber data.
• SIEM with 180-day log retention and 24x7 monitoring.
• Annual VAPT completed by a CERT-In empanelled firm with findings closed.
• Incident response plan with CERT-In 6-hour reporting capability tested.
• DR site with a successful half-yearly failover drill.
• DPDP consent, privacy notice and breach-notification process in place.
• Vendor contracts include security, audit-rights and breach clauses.
• Annual IS Audit and Cyber Security Audit reports available with remediation tracked.

Common gaps

• Policies exist on paper but are outdated, unapproved or not operationalised across all in-scope systems.
• MFA and PAM gaps on legacy or vendor-managed systems, and shared administrator accounts.
• Incomplete SIEM log-source coverage and log retention shorter than the CERT-In 180-day requirement.
• VAPT performed but critical findings left open beyond SLA, or no re-testing evidence.
• DR site present but drills are tabletop-only, with no near-live failover of NPS transaction systems.
• Weak third-party governance: missing due diligence, absent audit-rights clauses, no DPDP data-processing agreements.
• Production data present in test/dev environments without masking.
• CERT-In and PFRDA incident-reporting timelines not evidenced, and no forensic-readiness procedures.
• DPDP Act obligations (consent, purpose limitation, breach notification) not yet mapped to controls.
• Change management without segregation of duties or proper authorisation trails.

PFRDA Cyber Security mapped to other frameworks

Because most NPS intermediaries carry overlapping regulatory obligations, mapping PFRDA domains to adjacent frameworks lets a single control set satisfy multiple regulators. The mapping below is indicative and should be confirmed against each framework's current version.

Frequently asked questions

Need help with PFRDA Cyber Security?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.