Essential Cybersecurity Policies Every Indian Company Should Maintain
Why Cybersecurity Policies Matter for Indian Companies
Cybersecurity policies are not documents prepared only when an audit is approaching. They set out how security responsibilities should be handled across systems, employees, data, and day-to-day operations. They also give management and security teams a common reference when making decisions about access, data handling, incidents, vendors, and continuity.
For companies operating in India, these requirements are closely connected with the regulatory environment. The Digital Personal Data Protection Act 2023 has increased the focus on how personal data is collected, used, retained, and protected. CERT In requirements also affect areas such as cybersecurity practices and incident reporting. Companies in regulated sectors may have additional requirements from bodies such as RBI and SEBI.
A policy framework brings these requirements into a structured set of documents. Information security, data protection, access control, incident response, business continuity, vendor management, and employee security can each have defined requirements and responsibilities.
The policies also need to be implemented and reviewed. A document that is approved but not followed does not provide the same level of control as a policy supported by procedures, assigned responsibilities, employee awareness, and regular review. Changes in technology, regulations, internal processes, or security risks can also create a need to update the relevant policies.
What is a Cybersecurity Policy Framework
A company rarely relies on one policy to manage its security requirements. Information security may sit at the centre, with separate policies covering data protection, user access, acceptable use, incident response, continuity, vendors, and employee responsibilities. A Cybersecurity Policy Framework in India also needs to reflect the regulatory and security requirements that apply to the company.
The Information Security Policy can provide a broader security direction. Other policies then deal with specific areas. An access control policy can cover account provisioning, privileged access, authentication and access reviews. An incident response policy can set out how incidents are classified, escalated and handled. A vendor policy can address security requirements before and during a third-party relationship.
These policies also need to connect with the controls and procedures used by the relevant teams. If a policy requires periodic access reviews, there should be a process for carrying out those reviews and recording the results. If a policy requires incident reporting, employees and response teams should know where and how an incident needs to be reported.
The framework needs to be reviewed when the requirements change. A new system, a change in working practices, a security incident, a new supplier or a regulatory update can all affect an existing policy. Reviewing the relevant documents helps keep the written requirements aligned with the controls being used.
Essential Cybersecurity Policies Every Indian Company Should Maintain
The exact policies required will vary depending on the company’s systems, the information it handles, the people who have access to it, and the regulations that apply to its operations. Some companies may need separate policies for specific areas, while others may combine closely related requirements.
The purpose is to have clear rules for the areas where security decisions are made regularly. Who can access the system? How is personal data handled? What happens when an employee leaves? Who responds when a security incident is reported? These are the kinds of questions the policy framework needs to answer.
Information Security and Data Protection Policy
The Information Security Policy provides the overall direction for protecting information across systems, people, and processes. It normally covers security responsibilities, information asset classification and handling, risk management, and the legal or regulatory requirements that apply to the company.
Data protection sits closely alongside information security, but it has its own requirements. A data protection policy should address how personal data is collected and processed, the rights of data principals, retention and disposal, sharing with third parties, and the handling of personal data breaches.
For companies subject to the DPDP Act, these requirements need to be reflected in the way personal data is actually handled. A policy that only exists for documentation purposes will not address the underlying compliance risk.
Access Control and Acceptable Use Policy
Access should be linked to a person’s responsibilities. An employee working in finance, for example, should not automatically receive access to systems or information used by other departments.
The access control policy needs to cover account provisioning, changes to access, removal of access, privileged accounts, authentication requirements, and periodic access reviews. MFA should also be addressed where it is required for sensitive systems or higher-risk accounts.
Acceptable use covers the day-to-day use of company technology. This includes computers and mobile devices, email, internet access, cloud platforms and remote connections. If employees are permitted to use personal devices or external communication platforms for work, those arrangements need clear security requirements as well.
Incident Response and Cyber Crisis Management Policy
When a ransomware attack, phishing incident, data leak, or unauthorised access is detected, the response cannot depend entirely on people deciding what to do at the time.
An incident response policy establishes the basic process. It should define what qualifies as an incident, how incidents are classified, who needs to be involved, when an incident is escalated, and how response activities are documented.
Communication is another part of the process. Depending on the incident, there may be requirements to inform regulators, customers, management, service providers, or other stakeholders. Evidence and forensic information also need to be handled properly so that important details are not lost during the response.
Business Continuity and Disaster Recovery Policy
Security incidents are not the only reason an important system can become unavailable. Hardware failure, infrastructure problems, natural disasters and failures involving critical service providers can also interrupt operations.
A business continuity and disaster recovery policy should identify the activities that need to continue and the systems that support them. Business impact analysis, recovery priorities, recovery objectives, backup arrangements and restoration procedures form part of this planning.
Recovery plans also need to be tested. Testing can expose problems that are difficult to see in a document, such as an unusable backup, an unrealistic recovery target, or uncertainty about who is responsible for restoring a particular system.
Vendor and Third-Party Risk Management Policy
Third parties can introduce security risks that are outside the company’s direct environment. A cloud provider may host company data, a software provider may connect to internal systems, and a service provider may handle personal information on the company’s behalf.
Vendor assessment should therefore consider the security and privacy risks before access is provided. Contracts may need appropriate security requirements, privacy obligations, reporting requirements and other controls based on the service being provided.
The relationship should also be reviewed after onboarding. Changes in the service, new access requirements, security incidents or changes in the vendor’s role can alter the level of risk. When the contract ends, access should be removed, and company information should be returned, deleted or otherwise handled according to the agreed requirements.
Security Awareness and Human Resources Security Policy
Security controls are not limited to systems and software. Employees interact with company information every day, so security requirements need to be considered throughout the employee’s life cycle.
This can include background verification, confidentiality agreements, security awareness training, disciplinary procedures and controls for joining and leaving the company. Training should cover risks employees are likely to encounter, such as phishing, unsafe handling of information and inappropriate use of company systems.
Exit procedures deserve particular attention. User accounts, remote access, privileged permissions and company devices should be dealt with as part of the employee’s departure process.
Network, Vulnerability and Change Management Policy
Network and system security policies deal with the infrastructure that supports company operations. This can include devices, network connections, servers, applications and other systems that need to be protected from unauthorised access or misuse.
Vulnerability management adds another layer of control. Security weaknesses need to be identified, assessed and addressed according to their severity and the risk they present. The policy can also establish how vulnerability findings are recorded and tracked.
Changes to systems should follow a controlled process. A change may affect security or availability even when it appears routine, so appropriate review, approval, testing and documentation should take place before it is introduced into the environment.
Governance, Risk and Compliance Policy
Governance, risk and compliance bring different policy areas together. This includes identifying security risks, assessing their impact, tracking compliance requirements, reporting findings and following up on corrective actions.
Responsibilities should be clear at both operational and management levels. Internal audits and management reviews can then be used to see whether controls are working as intended and whether identified gaps are being addressed.
A GRC policy also provides a way to connect regulatory requirements with internal controls. When a regulation changes or a new risk is identified, the company can review the relevant policies and controls instead of treating each requirement as a separate exercise.
Indian Regulatory Requirements for Cybersecurity Policies
Cybersecurity policies also need to keep up with the requirements that apply to the company. The requirements are not the same for every sector. A company handling personal data has different obligations from a financial institution, for example, while companies working towards ISO 27001 have another set of controls to consider.
For Indian companies, the policy framework may need to take the DPDP Act, CERT In requirements, RBI or SEBI requirements, and ISO 27001 into account. These requirements should be reflected in the relevant policies rather than maintained as separate compliance documents that security teams rarely refer to.
Digital Personal Data Protection Act Requirements
The Digital Personal Data Protection Act, 2023, has brought greater focus to the way personal data is collected, used, stored, shared, and deleted.
A data protection policy therefore needs to cover the handling of personal data throughout its lifecycle. This includes consent and lawful processing, data principal rights, retention and disposal, third-party sharing, and the process followed when personal data is involved in a breach.
The policy also needs to match what happens in practice. If a company states that personal data is deleted after a defined retention period, there should be a process and control in place to carry this out. The same applies to access, data sharing, and breach reporting.
CERT In Cybersecurity and Incident Reporting Requirements
CERT requirements need to be considered when setting out cybersecurity and incident response responsibilities.
An incident response policy should make it clear what happens when a cybersecurity incident is identified. The response may involve the security team, IT team, management, legal teams, service providers, or other parties depending on the incident.
Incident records and evidence also need to be handled properly. Keeping the reporting responsibility unclear until an incident happens can create unnecessary delays, particularly when the incident involves systems, data, or third parties across different teams.
RBI and SEBI Cybersecurity Expectations
Additional requirements apply to companies operating in regulated sectors. RBI and SEBI have their own cybersecurity expectations, so the policies used by a financial institution or a SEBI-regulated entity cannot simply rely on a generic cybersecurity policy.
Areas such as access control, vulnerability management, incident response, monitoring, third party risk, and business continuity may need to be addressed according to the applicable regulatory requirements.
This is also where policy mapping becomes useful. A company can map regulatory requirements to the relevant policies and controls, making it easier to see what is already covered and where a gap exists.
ISO 27001 Policy and Control Alignment
ISO 27001 takes a broader view of information security. Policies form part of the Information Security Management System, alongside risk assessment, controls, responsibilities, procedures, monitoring, and management review.
The policy framework should therefore connect with the company’s actual security controls. For example, an access control policy should be supported by the access management processes used by IT teams. An incident response policy should correspond with the way incidents are actually reported, investigated, and escalated.
This connection becomes particularly important during an ISO 27001 audit. Having the policy document is not enough on its own. There should be evidence that the requirements have been implemented and are being followed.
How to Maintain and Review Cybersecurity Policies
Writing a policy is only the starting point. Once it is approved, people need to know what it requires and the relevant teams need to follow it during their regular work. A policy that sits in a shared folder and is rarely reviewed will eventually fall behind changes in systems, suppliers, regulations, and security risks.
Assign Policy Ownership and Responsibilities
Someone needs to be responsible for each policy. This does not necessarily mean one person writes and manages every document. Different policies may sit with different teams depending on the subject.
For example, IT or information security teams may manage access control and incident response requirements, while HR may have responsibilities for employee security. Data protection requirements may involve legal, privacy, IT, and other teams that handle personal data.
The owner should know when the policy was last reviewed, whether changes are required, and who needs to approve those changes. Responsibilities should also be clear enough that employees know where to go when they have a question about a policy.
Implement, Communicate, and Monitor Policies
A policy becomes useful when employees and relevant teams know what it requires and have a practical way to follow it.
New employees may need security awareness training, while existing staff may need periodic refreshers when policies change. Technical teams may also need procedures, configurations, or controls to support the requirements written in the policy.
Monitoring can then show whether those requirements are actually being followed. Access reviews, vulnerability reports, incident records, audit findings, training records, and other evidence can provide a clearer picture than the policy document alone.
Review Policies After Risks, Incidents, and Regulatory Changes
Policies should not remain unchanged for years simply because they have already been approved.
A security incident may reveal that a response procedure is unclear. A new cloud service may introduce a different access requirement. A regulatory change may require an existing privacy or reporting process to be updated. Even a change in the company’s internal structure can make an old policy difficult to apply.
These events are good reasons to review the relevant policy. Regular review should also be scheduled so that policies do not depend entirely on someone remembering to update them.
Common Mistakes in Cybersecurity Policy Management
Having a set of cybersecurity policies does not automatically mean that security requirements are being followed. Problems usually appear when the documents are written separately from the way systems, employees, suppliers, and security controls are actually managed.
Some companies also treat policy work as audit exercises. A document gets prepared, approved, and filed away until it is needed again. That creates a gap between policy and day-to-day security work.
Creating Policies Only for Compliance
Compliance is one reason to maintain cybersecurity policies, but it should not be the only reason.
A policy prepared just before an audit may contain the required statements without explaining how the requirements are handled internally. For example, an access control policy may say that access must be reviewed regularly, but the company still needs a process for carrying out those reviews and records to show that they were completed.
The same applies to incident response, data protection, vendor management, and business continuity. These policies need to reflect the controls and processes already being used by the relevant teams.
Using Generic Policies Without Risk Assessment
A standard policy template may provide a useful starting point, but it cannot account for every company’s system and risk.
The security requirements for a company using several cloud platforms will not necessarily be the same as those for a company operating mainly on its own infrastructure. The type of information being handled, critical applications, remote access, privileged accounts, suppliers, and regulatory requirements all affect the policy requirements.
Risk assessment should therefore be considered before finalising the policy. It can highlight areas that need stronger controls and prevent important risks from being missed simply because they were not covered in a generic template.
Failing to Review and Update Policies
A policy can remain approved while becoming less relevant to the environment it was written for.
Systems are replaced. New applications have been introduced. Employees may work remotely. A supplier may start handling data that was previously managed internally. Regulatory requirements can also be changed.
These changes can affect existing policy requirements. A significant security incident may reveal another reason for a review if the response process did not work as expected.
Policies should therefore be reviewed at defined intervals and whenever there is a significant change in technology, operations, suppliers, regulations, or security risk. The review should result in an update when the existing requirements no longer reflect how security is being managed.
Conclusion
A cybersecurity policy framework is useful when it reflects the way security is actually managed. The documents need to cover the areas that matter to the company, but having a long list of policies is not the goal.
Information security, data protection, access control, incident response, continuity, third-party security, employee responsibilities, and governance all need clear ownership and practical controls behind them.
The regulatory side also needs attention. DPDP requirements, CERT-In directions, sector-specific requirements, and standards such as ISO 27001 can affect what needs to be documented and how those requirements are maintained.
Policies should be reviewed when something changes, rather than being left untouched after approval. A security incident, a new system, a new supplier, or a regulatory update can all give a reason to revisit an existing policy.
When the documentation matches the controls and processes being used, policies become part of day-to-day security management rather than documents prepared only for an audit.
Frequently Asked Questions
What cybersecurity policies should an Indian company have?
The policies required depend on the company’s systems, data, industry, and regulatory requirements, but key areas generally include information security, data protection, access control, acceptable use, incident response, business continuity, disaster recovery, third party risk, employee security, vulnerability management, change management, and governance.
What is a cybersecurity policy framework?
A cybersecurity policy framework is a structured set of policies that define how security is managed across different areas of a company. It can bring information security, data protection, access control, incident response, third party security, employee responsibilities, and governance requirements into one connected framework, with each policy covering its own area of responsibility.
Are cybersecurity policies mandatory for Indian companies?
There is no single set of cybersecurity policies that applies to every Indian company. The requirements depend on the company’s industry, systems, data, and applicable regulations. Requirements under the DPDP Act, CERT In, RBI, SEBI, or standards such as ISO 27001 may create specific policy and control requirements for companies covered by them.
How often should cybersecurity policies be reviewed?
Cybersecurity policies should be reviewed regularly and whenever there is a significant change that could affect security requirements. A security incident, regulatory update, new technology, change in suppliers, or change in internal processes may require an earlier review rather than waiting for the next scheduled review.
How do cybersecurity policies support ISO 27001 compliance?
Cybersecurity policies form part of the Information Security Management System used for ISO 27001 and document security requirements, responsibilities, and management expectations. They need to be supported by actual controls, procedures, records, and reviews, because having a policy document alone does not demonstrate that the requirements are being implemented.