Cyber Security Audit Baseline Requirements (CSA-BR): All 68 Controls Explained

The CSA-BR at a glance

If your organisation is getting ready for a cyber security audit in India, there’s one short document you’ll keep running into: the Cyber Security Audit Baseline Requirements, or CSA-BR. It’s a 19-page PDF listing the 68 minimum controls an auditor checks, grouped into six areas, with rules on which ones are mandatory depending on how critical your systems are. You can download it from CERT-In’s website here: Cyber Security Audit Baseline Requirements (PDF).

We read it line by line, along with CERT-In’s 2025 audit policy that tells auditors and auditees to use it. Below you’ll find what the CSA-BR is, who has to follow it, all 68 controls in plain English with the evidence auditors usually ask for, and the skills a team needs to meet them.

	Details
What it is	A minimum, common baseline of controls to audit; the document calls itself the “minimum-security assurance baseline”
Published by	National Security Council Secretariat (NSCS), publication NSCS-46-16 Rev 1.0, October 2020, hosted on CERT-In’s website
Prepared with input from	CERT-In, the Ministry of Home Affairs, the National Informatics Centre, NCIIPC and the Defence Cyber Agency
Who must follow it	Mandatory for owners and regulators of Critical Information Infrastructure; all other public and private organisations are “strongly encouraged”
Size	68 controls (the document calls them “markers”) in six groups: Management 19, Protection 21, Detection 9, Response 11, Recovery 3, Lessons learnt 5
Risk levels	High: all 68 mandatory. Medium: 62 mandatory, 6 recommended. Low: 50 mandatory, 18 recommended
Why it matters now	CERT-In’s July 2025 audit policy says auditees and auditing organisations should use it to build their audit programme
Download	cert-in.org.in/PDF/CyberSecurityAuditbaseline.pdf

What the CSA-BR is, and who wrote it

It sits on CERT-In’s website, but the CSA-BR is a National Security Council Secretariat publication: NSCS-46-16, Revision 1.0, dated October 2020. It was put together with input from CERT-In, the Ministry of Home Affairs, the National Informatics Centre, the National Critical Information Infrastructure Protection Centre (NCIIPC) and the Defence Cyber Agency. CERT-In now links it from its auditor empanelment pages.

Its goal is simple: give government, auditors and the organisations being audited one common language, by acting as “a minimum, common, and harmonised baseline criterion for cyber security audits”. It is careful to add that it isn’t meant to push organisations away from risk-based security towards box-ticking compliance.

On who has to follow it, the wording is clear. It is mandatory for owners and regulators of Critical Information Infrastructure, and every other public and private sector organisation is “strongly encouraged” to follow it. It also calls itself “an evolving document”, although the copy on CERT-In’s site is still Revision 1.0 from 2020 (checked on 12 November 2026).

Two practical notes before you open it. The text mentions an “Annexure-A” table of markers, but in the published PDF the markers are in Section 7. And the document is licensed under Creative Commons BY-NC-SA 4.0, so you can adapt the control list into an internal checklist, as long as you credit it, don’t use it commercially, and share your version under the same licence.

Why it matters more since CERT-In’s 2025 audit policy

On 25 July 2025, CERT-In issued its Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0). Section 8 says the CSA-BR “should be used by auditees and auditing organizations to build their audit program”, and lists it next to ISO/IEC standards, the CSA Cloud Controls Matrix, OSSTMM3, the OWASP Web Security Testing Guide, ASVS, the Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model.

The same guidelines change how audits are run in ways that tie straight back to the baseline:

• At least once a year. Organisations being audited are expected to have a comprehensive audit of all their ICT systems at least once a year, and sector regulators can ask for more.
• Major changes get audited first. System overhauls, technology migrations and configuration changes that affect sensitive data or critical infrastructure must be audited before they go live.
• Short lists aren’t standards. OWASP Top 10 and SANS Top 25 “should not be considered as standards or references for audits”.
• Tools alone aren’t enough. Purely tool-based testing is discouraged, because it misses manual and non-automated parts of the setup.
• Findings are scored twice. Reports rate each finding with CVSS for severity and EPSS for how likely it is to be exploited.
• Scope is wider. Test/UAT, development and production environments belong in scope, and so does third-party and supply chain risk.

The guidelines say they are binding on CERT-In empanelled auditing organisations and on auditee entities “covered under the relevant provisions”. Whether your organisation must comply depends on your sector and regulator, so check that first. Either way, the CSA-BR is the checklist your auditor is likely to start from.

Auditee and auditor: who is responsible for what

The CSA-BR splits the work cleanly between the organisation being audited and the auditor.

Your organisation (the auditee) must

• Prepare and present the organisation’s cyber security posture
• Set up, maintain and document the minimum internal controls in the CSA-BR
• Choose which audit markers apply, based on a realistic risk assessment
• Identify the laws and regulations that apply, and comply with them
• Take management responsibility for the organisation’s cyber security posture
• Make the audit possible and support it

The auditor must

• Stay independent
• Understand the organisation’s internal controls and take them into account
• Audit in line with auditing standards
• Confirm the organisation follows its own controls, best practices and the CSA-BR controls

Notice the first auditee duty. You prepare and present your own security posture. The auditor checks your evidence; they don’t build it for you.

High, medium or low: how your risk level decides what’s mandatory

The CSA-BR asks each organisation to classify its own infrastructure as part of its risk assessment:

• High risk: an attack or outage would affect national security, public health and safety, the economy, critical government operations or the organisation’s own critical operations.
• Medium risk: the impact stays within the organisation and its dependencies, but its essential services are affected.
• Low risk: an attack or outage would have minimal impact on the organisation’s functions.

That classification decides how many controls are mandatory. Here’s the count for each group, with the controls that become “recommended” rather than mandatory at each level:

Control group	High risk	Medium risk	Low risk
Management (19)	All 19	All 19	15 (csm.11, csm.12, csm.14, csm.15 recommended)
Protection (21)	All 21	18 (pro.12, pro.13, pro.20 recommended)	16 (pro.12, pro.13, pro.16, pro.20, pro.21 recommended)
Detection (9)	All 9	8 (det.3 recommended)	5 (det.3, det.4, det.7, det.9 recommended)
Response (11)	All 11	9 (res.1, res.8 recommended)	8 (res.1, res.8, res.9 recommended)
Recovery (3)	All 3	All 3	All 3
Lessons learnt and improvements (5)	All 5	All 5	3 (imp.4, imp.5 recommended)
Mandatory in total	68	62	50

A few things stand out. Vulnerability assessment with fixes (pro.11) is mandatory at every level, but scheduled penetration testing (pro.12) is mandatory only for high-risk infrastructure. Daily log review of critical services (det.3) and a crisis plan aligned with the National Cyber Crisis Management Plan (res.1) are also high-risk only. Recovery controls are mandatory for everyone.

One caution: calling your infrastructure “low risk” to shorten the checklist won’t hold for long. Control csm.5 says the classification is affirmed during the audit, so the auditor can challenge it.

All 68 controls in plain English

Below is every marker, reworded in plain English. The “Mandatory at” column comes straight from the document’s tables. The last column is our own suggestion of the evidence auditors typically ask to see; the CSA-BR itself lists only the controls.

Management (csm.1 to csm.19)

ID	What the control asks for	Mandatory at	Typical evidence
csm.1	An information security policy and an audit process are defined and in place	All levels	Approved security policy; audit policy or calendar
csm.2	Recognised frameworks, standards or best practices are adopted for cyber security	All levels	Framework mapping (for example to ISO/IEC 27001)
csm.3	Senior management is committed	All levels	Management meeting minutes, signed policy, approved budget
csm.4	Infrastructure components are identified and prioritised by criticality	All levels	Critical asset list with ratings
csm.5	Infrastructure is classified as High, Medium or Low risk in line with business processes; the audit affirms the classification	All levels	Risk classification and the reasoning behind it
csm.6	Hardware, software, systems, applications and network components are inventoried	All levels	Current asset inventory
csm.7	Threats, vulnerabilities, likelihoods and impacts are identified	All levels	Threat and vulnerability assessment
csm.8	Cyber security risks are identified	All levels	Risk register
csm.9	The risk management approach is effective and fits business processes	All levels	Risk methodology and review records
csm.10	A risk treatment plan exists, and accepted or residual risk matches how critical the function is	All levels	Risk treatment plan; signed risk acceptances
csm.11	A continuity plan for critical functions (business continuity plan) is in place	High, Medium	Approved BCP
csm.12	The continuity plan keeps the minimum security controls defined and working	High, Medium	BCP section on security during disruption
csm.13	Security roles and responsibilities are defined, communicated and trained on	All levels	Role descriptions; training records
csm.14	Enough people and resources are allocated to the security function	High, Medium	Organisation chart, staffing plan, budget
csm.15	A cyber security crisis management plan is developed, implemented and exercised	High, Medium	Crisis plan and exercise reports
csm.16	Legal, regulatory and sector-specific security requirements are identified and followed	All levels	Compliance register
csm.17	Management makes sure audit findings are acted on	All levels	Closure tracker for earlier audit findings
csm.18	Data is identified and labelled, and its owners, custodians and users know their responsibilities	All levels	Data classification policy; labelled data inventory
csm.19	Administrative, physical and technical access controls, and the access-control model, are identified	All levels	Access control policy

Protection (pro.1 to pro.21)

ID	What the control asks for	Mandatory at	Typical evidence
pro.1	Physical security controls protect critical assets	All levels	Server-room access logs, CCTV, visitor register
pro.2	Access controls are implemented in the chosen model	All levels	User access reviews; privileged account list
pro.3	Remote access and teleworking are controlled	All levels	Remote access policy; VPN and MFA settings
pro.4	Malware protection is in place and shown to work	All levels	Endpoint protection coverage and update reports
pro.5	Vulnerability and patch management works effectively	All levels	Patch compliance reports
pro.6	Removable media and BYOD/BYOT are controlled	All levels	USB policy; device management settings
pro.7	Wireless networks are secured	All levels	Wi-Fi configuration; rogue access point checks
pro.8	Hardware, software, industrial control systems, network devices and applications are securely configured	All levels	Hardening baselines; configuration review reports
pro.9	A secure software development lifecycle is followed, in-house and outsourced	All levels	SDLC policy; application security test reports
pro.10	Perimeter devices (firewall, IDS/IPS, network monitoring) are deployed and monitored continuously	All levels	Firewall rule reviews; monitoring records
pro.11	Vulnerability assessment and fixes happen continuously, by the internal team and an empanelled third party	All levels	Internal and third-party VA reports; fix tracker
pro.12	Penetration testing is scoped and carried out periodically	High only	Pentest scope documents and reports
pro.13	The organisation takes part in national, sectoral or internal cyber security exercises	High only	Exercise participation records
pro.14	Role-based security training and awareness run periodically for all employees and associated external entities	All levels	Training calendar and attendance
pro.15	Training content is appropriate	All levels	Training material mapped to roles
pro.16	BCP and disaster plans are tested periodically, including whether security controls keep working	High, Medium	DR drill reports
pro.17	Data is protected in transit and at rest	All levels	Encryption and TLS settings
pro.18	Data retention and destruction policies are defined and followed	All levels	Retention schedule; destruction records
pro.19	Change control policy and practice are defined and followed	All levels	Approved change tickets
pro.20	The supply chain is mapped and secured, including vendors meeting the baseline	High only	Vendor list; vendor security assessments
pro.21	IT equipment is disposed of securely	High, Medium	Disposal and data-wiping certificates

Detection (det.1 to det.9)

ID	What the control asks for	Mandatory at	Typical evidence
det.1	The scope, method and frequency of log collection are defined and implemented	All levels	Logging policy; list of log sources
det.2	Alerts and logs from security devices are analysed regularly	All levels	SOC procedures; alert review records
det.3	Logs of critical services are analysed daily	High only	Daily review records or SOC shift reports
det.4	Accounts and access are monitored	High, Medium	Privileged access monitoring; login anomaly alerts
det.5	The network is monitored	All levels	Network monitoring or IDS records
det.6	Physical security controls are monitored for possible cyber incidents	All levels	Physical access alerts linked to the incident process
det.7	There are enough people for log and alert analysis, with clear roles	High, Medium	SOC staffing and role descriptions
det.8	Systems are synchronised to a single time source	All levels	NTP configuration
det.9	Detected incidents are analysed technically for cause, impact and attacker method	High, Medium	Incident analysis reports

For det.8, keep CERT-In’s 28 April 2022 directions in mind as well. They require service providers, intermediaries, data centres, body corporates and government organisations to sync all ICT system clocks with the NTP servers of NIC or NPL (or servers traceable to them), and to keep logs of all ICT systems for a rolling 180 days within India.

Response (res.1 to res.11)

ID	What the control asks for	Mandatory at	Typical evidence
res.1	A cyber crisis management plan in line with the National Cyber Crisis Management Plan is in place	High only	Crisis management plan
res.2	An incident response plan is implemented	All levels	Incident response plan and records
res.3	Incident response roles and responsibilities are clearly defined	All levels	Response team roster
res.4	An incident escalation matrix is defined	All levels	Escalation matrix
res.5	Internal communication during incidents is clearly defined	All levels	Internal communication plan
res.6	Communication with stakeholders and agencies during incidents is clearly defined	All levels	External communication procedure
res.7	Contact details of ministries, stakeholders, vendors and agencies such as NCIIPC and CERT-In are documented and current	All levels	Contact directory with a review date
res.8	An incident and abuse reporting channel is defined and working	High only	Reporting mailbox or portal
res.9	Information sharing with external entities is defined and implemented	High, Medium	Information-sharing procedure
res.10	Incidents are recorded and investigated for impact, the vulnerability used or tried, attacker method and source	All levels	Incident register; investigation reports
res.11	Incidents are contained and mitigated	All levels	Containment and closure records

The same 2022 directions require listed types of cyber incidents to be reported to CERT-In within 6 hours of noticing them, which is one more reason res.4 (escalation) and res.7 (agency contacts) need to be current before something goes wrong.

Recovery (rec.1 to rec.3)

ID	What the control asks for	Mandatory at	Typical evidence
rec.1	A recovery plan is defined and implemented	All levels	Recovery plan
rec.2	Resources are available to recover critical functions	All levels	Recovery resources and backup records
rec.3	The recovery plan includes lessons learnt from crises and incidents	All levels	Plan revision history

Lessons learnt and improvements (imp.1 to imp.5)

ID	What the control asks for	Mandatory at	Typical evidence
imp.1	Lessons from incidents and exercises are added to the response plan	All levels	Post-incident reviews; plan updates
imp.2	Lessons learnt and improvement plans are documented, with management commitment	All levels	Improvement plan signed off by management
imp.3	The crisis management plan and incident handling procedures are improved and updated	All levels	Version history of both documents
imp.4	Security posture has improved since the last reference point (last assessment, last year)	High, Medium	Comparison with the previous audit
imp.5	Performance improves across successive exercises and training	High, Medium	Exercise scorecards over time

How to prepare for an audit against the CSA-BR

If an audit is coming up, this is the order we’d work in:

• Classify first. Decide whether each part of your infrastructure is high, medium or low risk, and write down why (csm.4, csm.5). Everything else depends on this.
• Build an evidence register. One row per applicable marker: owner, where the evidence lives, and status. It shows your gaps quickly and gives the auditor one place to look.
• Reuse what you already have. If you run ISO/IEC 27001 or follow a sector regulator’s framework, map those controls to the markers instead of writing a second set of documents.
• Fix the technical basics early. Asset inventory (csm.6), patching (pro.5), vulnerability assessment (pro.11), log collection (det.1) and time sync (det.8) all need a track record behind them, so start them early.
• Test your plans. Run a tabletop exercise on the incident response and crisis plans and a disaster-recovery drill. These produce the evidence for csm.15, pro.16 and imp.1.
• Agree the scope with your auditor. Under CERT-In’s 2025 guidelines, scope should include test/UAT, development and production, plus third-party risk.
• Close findings and show progress. Track every finding to closure (csm.17), because the next audit will check whether your posture improved (imp.4).

Small business? CERT-In has separate, lighter guidance for MSMEs, which we covered in our CERT-In guided cybersecurity checklist for MSMEs. If personal data is involved, our DPDP Act and cybersecurity guide covers the extra obligations.

The skills behind each control group

A baseline is only as good as the people running it. Most CSA-BR controls map to a specific job and skill set, and two of them ask directly whether you have enough people: csm.14 for the security function and det.7 for log and alert analysis. Here’s how the groups line up with roles and training:

Control group	Who usually owns it	Skills it needs	Related training
Management	CISO, GRC and risk analysts, internal audit	Risk assessment, policy writing, framework mapping, audit follow-up	EC-Council C|CISO; see our GRC certification guide for CISA, CISM and ISO 27001 Lead Auditor
Protection	Security engineers, VAPT analysts, application security teams	Vulnerability assessment, pentest scoping and testing, secure configuration, secure SDLC	CEH v13, CPENT, OSCP+ (PEN-200); OSWA and OSWE for web apps
Detection	SOC analysts and threat hunters	Log analysis, SIEM work, network monitoring, alert triage	Certified SOC Analyst, SOC-200, CompTIA CySA+
Response	Incident handlers and response leads	Response planning, containment, escalation, investigation	EC-Council E|CIH; CHFI for investigations (det.9, res.10)
Training and awareness (pro.14, pro.15)	Security team with HR	Role-based training plans that fit each team	Corporate cybersecurity training

If you’re building a career here, our SOC analyst roadmap and E|CIH vs GCIH comparison go deeper on the detection and response side.

Frequently asked questions

Is the CSA-BR mandatory for private companies?

It is mandatory for owners and regulators of Critical Information Infrastructure. Every other public and private organisation is “strongly encouraged” to follow it. Separately, CERT-In’s 2025 Comprehensive Cyber Security Audit Policy Guidelines say auditees and auditing organisations should use the CSA-BR to build their audit programme, and those guidelines bind empanelled auditors and auditee entities covered under the relevant provisions. Check your sector regulator’s rules to see where you stand.

How many controls are in the CSA-BR?

68 controls, which the document calls markers, in six groups: Management (19), Protection (21), Detection (9), Response (11), Recovery (3) and Lessons learnt and improvements (5). All 68 are mandatory for high-risk infrastructure, 62 for medium risk and 50 for low risk.

Does the CSA-BR require penetration testing?

Scoped, periodic penetration testing (pro.12) is mandatory for high-risk infrastructure and recommended for medium and low risk. Continuous vulnerability assessment with corrective action (pro.11), by the internal team and an empanelled third party, is mandatory at every level.

How often should an organisation be audited against it?

The CSA-BR doesn’t set a frequency itself. CERT-In’s 2025 audit guidelines say audits should happen at least once a year, that sector regulators can require more, and that major changes need an audit before they go live.

What’s the difference between the CSA-BR and ISO 27001?

ISO/IEC 27001 is an international, certifiable standard for running an information security management system. The CSA-BR is a short Indian baseline of what an auditor should check. They work together: CERT-In’s 2025 guidelines list ISO/IEC standards and the CSA-BR side by side, and most organisations map their existing ISO controls to the CSA-BR markers.

Is there a newer version than the 2020 document?

Not as of 12 November 2026. The PDF on CERT-In’s website is Revision 1.0 from October 2020. The document says it will evolve, so check CERT-In’s website before each audit cycle.

Who publishes the CSA-BR, CERT-In or NSCS?

The National Security Council Secretariat publishes it (NSCS-46-16), with input from CERT-In, the Ministry of Home Affairs, NIC, NCIIPC and the Defence Cyber Agency. CERT-In hosts the PDF and points to it in its 2025 audit guidelines.

References & further reading

• Cyber Security Audit Baseline Requirements, NSCS-46-16 Rev 1.0, October 2020 (PDF on CERT-In’s website)
• CERT-In: Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, 25 July 2025 (PDF)
• CERT-In: Directions under section 70B(6) of the IT Act, 28 April 2022 (PDF)
• CERT-In: list of empanelled information security auditing organisations (PDF)

Where to go from here

If you own an upcoming audit, download the CSA-BR, settle your risk level, and build the evidence register before anything else. If you’re building a security career, notice how much of this baseline depends on hands-on skills: vulnerability assessment, log analysis and incident handling come up in almost every group.

Our parent company, Macksofy Technologies Pvt Ltd, is on CERT-In’s list of empanelled information security auditing organisations. That is an audit empanelment, not a training accreditation.

This guide summarises public documents for learning purposes and is not legal advice. It reflects the CSA-BR (Revision 1.0, October 2020) and CERT-In’s audit guidelines (Version 1.0, July 2025) as published on 12 November 2026. Check the latest versions on CERT-In’s website and your sector regulator’s rules before planning an audit.