AS | Ankit Sarawagi|Founder, CFOmatrix·June 2026·12 min read | Updated Jun 2026 |
- The information security policy is the parent document: it sets direction and points to detailed sub-policies (access control, acceptable use, incident response and more).
- It is the first artefact auditors request in a SOC 2 or ISO 27001 review, because every control should trace back to it.
- In India it is the practical way to evidence the reasonable safeguards required by the DPDP Act 2023 and the readiness to meet CERT-In 6-hour incident reporting.
- A usable policy names roles, scope, and a yearly review cycle, and is approved and communicated, not just filed.
- Adapt a proven template: download the free information security policy template (Word) below and edit it to your stack and stage.
| 6 hours CERT-In window to report certain cyber incidents | Annual Minimum review cycle SOC 2 and ISO 27001 expect to see | #1 The first document auditors and customer security teams ask for |
What an Information Security Policy Is (and Is Not)
An information security policy is the top-level document that states how your company protects its information and systems. In one place it sets your objectives for the confidentiality, integrity and availability of data, assigns responsibility for security, and declares the rules that everyone in the business must follow. It is short on technical detail by design: its job is to set direction and authority, then point to the detailed sub-policies that do the heavy lifting.
It is not a procedure manual, a network diagram, or a list of firewall rules. Those are operational artefacts. The policy sits above them. Think of it as the constitution of your security program: every control, standard and procedure should be able to trace its authority back to a line in this document.
It is also not a one-time document. A policy that was written for an audit, approved once and never opened again fails the moment an auditor asks for evidence of review, or an incident exposes a rule nobody was following. A credible policy is approved by management, communicated to staff, and revisited on a fixed cycle.
The most common mistake is writing one giant document that mixes high-level direction with detailed procedures. Keep the parent policy short and stable, and let the sub-policies carry the detail that changes more often. Auditors prefer this structure too, because it makes change control easier to evidence.
What an Information Security Policy Must Cover
A complete information security policy answers a predictable set of questions. If your document covers the areas below, you have a defensible parent policy. The template linked above is structured around exactly these headings.
- Purpose, scope and objectives. What the policy is for, which systems, data, people and locations it applies to, and your CIA (confidentiality, integrity, availability) goals.
- Roles and responsibilities. Who owns and approves security, who runs it day to day, and the duty of every employee and contractor to comply.
- Risk management. How you identify, assess and treat information security risks, and how often.
- Data classification and handling. Categories (for example public, internal, confidential, restricted) and the handling rules for each.
- Access control. Least-privilege, joiner-mover-leaver process, multi-factor authentication, and review of access rights.
- Acceptable use. How company assets, email, internet and devices may and may not be used.
- Encryption and key management. Encryption of data in transit and at rest, and how keys are handled.
- Vendor and third-party security. Due diligence and contractual safeguards for processors and sub-processors.
- Physical and environmental security. Office, device and media controls, even in a remote-first setup.
- Change and configuration management. How changes to systems are reviewed and approved.
- Incident response and breach notification. How incidents are detected, reported, escalated and disclosed, including statutory timelines.
- Business continuity and backup. Backups, recovery objectives, and how the business keeps running after disruption.
- Compliance, review and enforcement. The laws and frameworks you align to, the review cycle, and the consequences of non-compliance.
Do not pad the parent policy with paragraphs of detail for each area above. State the principle (for example “access is granted on a least-privilege basis and reviewed quarterly”), then reference the access control sub-policy for the mechanics. Short and enforced beats long and ignored.
How It Anchors a SOC 2 / ISO 27001 Program
If you sell to other businesses, a customer security questionnaire or a contract clause will eventually ask whether you hold SOC 2 or ISO 27001. In both, the information security policy is the foundation the rest of the program is built on.
ISO 27001 is the international standard for an Information Security Management System (ISMS). It makes a documented, approved and communicated information security policy a mandatory clause: top management must establish it, align it to the organisation’s objectives, and review it. Annex A controls then break out into the detailed sub-policies. Without a parent policy, there is no ISMS to certify.
SOC 2 is an attestation report against the Trust Services Criteria (security, and optionally availability, confidentiality, processing integrity and privacy). It is less prescriptive about document titles, but the auditor still expects to see a written security policy that management has approved, and they will test whether your real controls match what the policy claims. A Type II report tests those controls over a period, so the policy needs to have been operating, not just written.
| ISO 27001 | SOC 2 | |
|---|---|---|
| What it is | Certification against a standard (ISMS) | Attestation report by an auditor |
| Policy required? | Yes, a mandatory clause | Yes, expected and tested |
| Framework | Annex A controls | Trust Services Criteria |
| Role of the policy | Top of the ISMS; everything maps to it | Management’s stated intent; controls are tested against it |
An auditor does not fail you for a policy that is missing a fancy clause. They fail you when the policy claims a control you do not actually run, or when you cannot show it was approved and reviewed. Write what you genuinely do, then close the gaps. A policy you can live up to is worth more than an aspirational one you cannot.
The Sub-Policies It References
The information security policy is a parent. The detail lives in sub-policies that it points to. You do not need every one on day one, but you should reference each as you mature so the structure is clear to an auditor or a customer.
| Sub-policy | What it governs |
|---|---|
| Acceptable Use Policy | How employees may use company devices, email, internet and assets |
| Access Control Policy | Least-privilege, MFA, joiner-mover-leaver, periodic access reviews |
| Password & Authentication Policy | Credential standards, MFA, secrets handling |
| Data Classification & Handling | Data categories and the rules for storing, sharing and disposing of each |
| Encryption Policy | Encryption in transit and at rest, and key management |
| Incident Response Policy | Detection, escalation, breach notification and timelines |
| Vendor / Third-Party Risk | Due diligence and contractual safeguards for suppliers and processors |
| BYOD & Remote Work | Personal devices, home networks and remote access controls |
| Backup, BCP & Data Retention | Backups, recovery objectives, retention periods and secure disposal |
Each of these is a standalone template in our policy library. The parent information security policy simply references them by name, so you can update a sub-policy without re-approving the whole framework. You can see all 41 policy templates in one place.
India: DPDP Act 2023 and CERT-In
There is no single Indian law that orders you to keep a document titled “information security policy.” But two obligations make one a practical necessity for any company that handles data.
The Digital Personal Data Protection Act 2023 (DPDP Act) requires a data fiduciary to put in place reasonable security safeguards to protect personal data, gives data principals rights over their data (such as access, correction and erasure), and requires breach notification to the Data Protection Board and to affected individuals. A written information security policy, with its incident response and data handling sub-policies, is how you demonstrate that those safeguards exist and that you can respond to a breach in an orderly way.
Separately, the CERT-In directions require organisations to report certain categories of cyber incident within 6 hours of noticing them, to maintain logs, and to synchronise system clocks. Your incident response sub-policy should bake in this 6-hour clock so the team is not reading the law for the first time during a live incident.
The 6-hour CERT-In window is far tighter than most teams assume. If your policy says “report incidents promptly” but does not name the 6-hour rule, the contact at CERT-In and an internal owner, you will lose hours you do not have. Make the timeline and the owner explicit in the incident response sub-policy.
Roles, Approval and the Review Cycle
A policy with no named owner and no review date is the easiest thing for an auditor to challenge. Spell out three things clearly.
- Ownership and approval. Management owns and approves the policy, typically through an information security officer or CISO. In a startup this is often the CTO or a founder. Name the role, not just a person, so it survives staff changes.
- Everyone’s responsibility. Every employee and contractor is responsible for following the policy. Tie this to onboarding, an acknowledgement record, and periodic security awareness training.
- Review cadence. Review at least annually, and after any major change: a serious incident, a new system or product, a change in law, or a new compliance or customer requirement. Record the review date, reviewer and approval inside the document.
Put a small version-control table at the top of the policy: version number, date, author, approver and a one-line summary of what changed. This single table answers the “show me evidence of review and approval” question that comes up in every SOC 2 and ISO 27001 audit.
How to Write Your Information Security Policy
You do not need to start from a blank page. Here is the fastest route from the template to an approved, working policy.
| Start from the template and set the scope |
Download the template, then define what is in scope: which systems, data, people and locations. A clear scope keeps the policy honest and the audit narrow.
| Write what you actually do |
Edit each section to match your real controls, not an aspiration. Where there is a gap between the template and reality, decide whether to fix the control or soften the statement, then track the gap.
| Reference the sub-policies and India obligations |
Point to each sub-policy by name, and embed the DPDP Act safeguards and the CERT-In 6-hour timeline so the legal obligations are not floating outside the framework.
| Approve, communicate and set the review date |
Get management sign-off, share it with every employee with an acknowledgement, fill in the version table, and diarise the next annual review. The policy is now live, not just written.
“The best information security policy is the shortest one you can actually live up to. Write what you do, point to the detail, and review it every year. Auditors reward honesty, not length.”
Ankit Sarawagi, CFOmatrixFrequently Asked Questions
What is an information security policy?
An information security policy is the top-level document that states how your company protects its information and systems. It sets the rules for confidentiality, integrity and availability of data, defines who is responsible for security, and acts as the parent document for detailed sub-policies such as access control, acceptable use and incident response. It is the document auditors ask for first in a SOC 2 or ISO 27001 review.
What should an information security policy cover?
A complete information security policy covers scope and objectives, roles and responsibilities, risk management, data classification, access control, acceptable use of assets, password and authentication rules, encryption, vendor and third-party security, physical security, change management, incident response and breach notification, business continuity, and the review and approval cycle. It should also reference the laws it helps you meet, such as the DPDP Act 2023 and CERT-In reporting.
Do I need an information security policy for SOC 2 or ISO 27001?
Yes. Both frameworks require a documented, approved and communicated information security policy. ISO 27001 makes it a mandatory clause of the Information Security Management System (ISMS). SOC 2 expects policies that map to the Trust Services Criteria. In both audits it is usually the first artefact requested, because it shows management has set the direction and the rest of the controls flow from it.
Is an information security policy legally required in India?
There is no single law that says you must have a document titled information security policy. However, the Digital Personal Data Protection Act 2023 requires reasonable security safeguards for personal data and breach notification to the Data Protection Board, and CERT-In directions require reporting certain incidents within 6 hours. A written policy is the practical way to demonstrate that you have these safeguards in place, so most B2B and data-handling companies treat it as mandatory.
Who owns the information security policy?
Management owns and approves the policy, usually through a designated information security officer, CISO or, in a startup, the CTO or founder. They are accountable for the policy. Every employee and contractor is responsible for following it. The policy should name these roles explicitly so accountability is clear during an audit or after an incident.
How often should an information security policy be reviewed?
At least once a year, and also after any major change: a significant security incident, a new product or system, a change in applicable law, or a new customer or compliance requirement. ISO 27001 and SOC 2 both expect to see evidence of periodic review and approval, so record the review date, the reviewer and the approval in the policy itself.
What sub-policies sit under the information security policy?
The information security policy is a parent document. Common sub-policies it references include the acceptable use policy, access control policy, password and authentication policy, data classification and handling policy, encryption policy, incident response policy, vendor or third-party risk policy, BYOD and remote work policy, backup and business continuity policy, and a data retention and disposal policy. The parent policy points to each one rather than repeating the detail.
This article is general information for India as of 2026 and is not legal, compliance or security advice. Laws and framework requirements change and apply differently to each organisation. Verify the current DPDP Act rules, CERT-In directions and audit requirements, and consult a qualified adviser before relying on any policy for your specific situation.
- All 41 HR, Finance & Security Policy Templates (India)Policies & Templates · CFOmatrix
- Acceptable Use Policy: What to Include and a Free TemplatePolicies & Templates · CFOmatrix
- Incident Response Policy: CERT-In, DPDP and a Free TemplatePolicies & Templates · CFOmatrix
AS | Founder, CFOmatrix | Finance Strategy & Equity Compliance CFOmatrix is a knowledge platform focused on how finance actually works inside growing companies. Every insight is shaped by real operating experience across startups and growth-stage companies, including cross-border setups. |