Information security policy, Quillmark Software
Information security policy template with a controls table by risk area
An information security policy has to say which risks matter, which control answers each one, who owns it, and how anyone can check it is working. This six page policy for a 40 person software company serving 610 customers does that in a nine row controls table, then sets access levels, incident response timeframes and the review cycle that keeps it true.
The document, page by page
Every page as it renders and as it prints, with nothing summarised. Read the wording before you reuse it.
Section by section
What each section is for, so you can keep the ones you need and drop the rest.
- Cover
- Executive cover with the company, title, purpose line and date.
- 1 to 3. Scope, roles and data classes
- 40 staff and 610 customers, who owns what, and four data classes with handling rules.
- 4. Controls by risk area
- Nine risks with control, owner and evidence.
- 5 and 6. Access
- Five access levels and joiner, mover and leaver steps.
- 7 to 9. Devices, development and monitoring
- Company laptops, secure development rules, central logging and alert response times.
- 10. Incident response
- Six steps with timeframes and the customer and regulator notice callout.
- 11 to 13. Backups, exceptions and training
- Recovery targets, the 90 day exception rule and yearly training.
- 14 and 15. Review cycle and breaches
- Monthly, quarterly and yearly checks, and how breaches are handled.
How to adapt this document
First, rewrite the controls table around your own top risks rather than copying all nine; a business without source code drops malicious code and adds, for example, payment fraud with a call back rule. Second, set recovery targets you have actually tested, not ones you hope for, and record the time of your first restore before publishing them. Third, if you hold health or card data, add the specific obligations for that data, such as card industry standards, as their own rows with an owner, instead of folding them into general encryption.
Frameworks behind the controls
The controls follow common ground between public frameworks: the NIST Cybersecurity Framework's identify, protect, detect, respond and recover functions, the Australian Essential Eight's emphasis on multi factor authentication, patching and backups, and the UK National Cyber Security Centre's small business guide. None of them is law for a private company, but customers and insurers increasingly ask which one a policy follows. Privacy and breach notification law in each country where customers are located sets the legal floor.
What makes this document work
Every control has an owner and evidence
The controls table pairs nine risk areas with a control, an owner and the evidence: account takeover with phishing resistant multi factor and an identity provider report, data loss with daily backups and a restore test log. Clause 4 adds that a control without evidence is treated as not in place.
Production access is the exception
The access table runs from Standard for all staff to Administrator for three named people, and Production is granted per task, approved each time by the platform lead, and expires after 8 hours. Most breaches at small software firms ride on standing access nobody remembered granting.
Incident steps carry clocks
The timeline gives each step a deadline: triage within 1 hour, containment within 4 hours for high severity, customer notice within 72 hours, review within 10 business days. The callout adds that regulator deadlines differ by country and can start at discovery, so the incident lead checks them with legal advice.
Questions people ask
What is the difference between an information security policy and an acceptable use policy?
An information security policy sets the organisation's controls and who owns them, and is written for managers, engineers and auditors. An acceptable use policy tells every staff member what they may and may not do with systems. Most organisations need both, and the second usually points to the first.
Does a small company need to follow ISO 27001?
Not unless a customer or contract requires certification. Many small software companies start from a framework such as the NIST Cybersecurity Framework, the Essential Eight or the UK small business guide, then grow towards ISO/IEC 27001 when enterprise customers ask. A policy like this one, with owners and evidence, is the starting point for any of them.
What are recovery point and recovery time objectives?
The recovery point objective is how much data you can afford to lose, measured in time; 24 hours here means at most a day of bookings. The recovery time objective is how long the service can be down; 8 hours here. Both should be tested, which is why clause 11 requires a quarterly restore rehearsal.
How often should access be reviewed?
Quarterly for most systems, and immediately when someone changes role or leaves. Clause 6 ties leavers and movers to the HR system so removal happens on the day, and the review cycle table schedules a quarterly access review signed by each team lead. Yearly reviews tend to miss months of stale access.
Who should approve exceptions to the policy?
Someone senior who did not ask for the exception and who answers for the risk, here the Head of Engineering. Each exception needs a reason, a compensating control and an end date of no more than 90 days, and open exceptions are reported to the board. Without an end date, exceptions become the real policy.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make one like thisOther document examples
Acceptable use policy template with an honest monitoring notice
An acceptable use policy has to say which systems it covers, what staff may and may not do with them, what the organisation monitors, and what happens when the rules are broken. This four page policy for a 28 person accounting firm holding records for 1,900 clients does that, with a monitoring table that says what is logged, for how long, and what is never watched.
Social media policy template that separates personal and official accounts
A social media policy has to tell staff two different things: how the organisation's official accounts are run, and what they can and cannot say about work on their own accounts. This four page policy for a council with 400 staff puts the two side by side in a table, then sets out what not to post, a disclosure rule and how breaches are handled.
Onboarding policy template with a 90 day schedule and an owner for each step
An onboarding policy has to make a new starter productive and connected quickly, which means saying what happens when, who is responsible, and which training cannot be skipped. This three page policy for an 85 person software company does that with a six row schedule from before day one to day 90, seven training modules with deadlines and a buddy program with set hours.
Want the steps in the builder? Read Create a document with AI, then Document builder components. For everything this generator can do, see the document maker.
Written and checked by the OneCraft team. Last checked .