2026-10-03 · policy
Acceptable use policy (sample)
A short, readable acceptable use policy of the kind that people will actually read and follow.
Purpose and scope
This policy sets out how the organisation's systems, data and accounts may be used. It applies to employees, contractors and anyone else given access.
Acceptable use
- Use systems primarily for work. Limited personal use is fine if it does not affect your work, security or other people.
- Protect your credentials: use multi-factor authentication and never share accounts.
- Keep devices and software up to date and use only approved software.
- Handle data according to its classification and share it only with those who need it.
- Report lost devices and suspected incidents immediately.
Not permitted
- Bypassing or disabling security controls.
- Accessing systems or data you are not authorised to use.
- Installing unapproved software or connecting unmanaged devices.
- Storing organisation data in personal cloud accounts.
- Scanning or testing systems without written approval.
- Using systems for illegal, harassing or discriminatory activity.
Monitoring
Systems are monitored for security and operational purposes, including logging and endpoint and network monitoring. Monitoring is proportionate, limited to those purposes and carried out in line with applicable law.
Enforcement and exceptions
Breaches may lead to loss of access and disciplinary action. Exceptions need written approval from the security owner and carry an expiry date. This policy is reviewed every year.
2026-10-03 · incident response
Incident response plan (sample)
A one-page incident response plan: who does what, how serious it is, and what happens in each phase.
Roles
- Incident lead: owns decisions and the overall timeline.
- Technical lead: investigates, contains and recovers.
- Communications lead: internal and external messages.
- Scribe: keeps the timeline of events and decisions.
- Executive sponsor: approves decisions with business impact.
Severity levels
- Severity 1: confirmed compromise of critical systems or sensitive data, or business-stopping impact. Engage immediately, any hour.
- Severity 2: likely compromise or significant impact contained to a limited area. Engage within one hour.
- Severity 3: suspicious activity with no confirmed impact. Same business day.
- Severity 4: policy violations and minor events. Next business day.
Response phases
- Preparation: contacts, access, logging and tooling are in place and tested.
- Detection and analysis: confirm the event, scope it, set a severity and open the timeline.
- Containment: stop the spread while preserving evidence, choosing the least disruptive effective option.
- Eradication and recovery: remove the cause, restore from known-good sources, monitor closely afterwards.
- Post-incident review: blameless review within two weeks, with owned and dated actions.
Communication
Share information on a need-to-know basis through a dedicated channel. Legal and regulatory notification duties are assessed by the incident lead with legal counsel, and only the communications lead speaks externally.
Evidence handling
Capture logs, memory and disk images before making changes where practical, record who handled what and when, and store copies with hashes in restricted storage.
Testing
Run a tabletop exercise at least twice a year. Review the plan after every Severity 1 or 2 incident and at least annually.
2026-10-03 · vendor risk
Vendor security assessment checklist (sample)
A framework for judging a supplier's security before data or access is shared with them.
Governance and assurance
- Is there an independent audit or certification (for example SOC 2 Type II or ISO/IEC 27001), and does its scope cover the service you will use?
- Are security policies documented and reviewed at least yearly?
- Is there a named person responsible for security?
Access control
- Is single sign-on and multi-factor authentication supported and enforceable?
- Is access least-privilege, with administrator actions logged?
- Are joiners, movers and leavers handled promptly?
Data protection
- Is data encrypted in transit and at rest?
- Where is data stored and processed?
- What are retention and deletion terms on exit?
- Are backups encrypted and restore-tested?
Secure development and vulnerability management
- Is there code review and dependency scanning in the development process?
- Is an independent penetration test done yearly, with a summary available?
- What are the patching timelines by severity?
- Is there a published way to report vulnerabilities?
Logging and incident response
- How long are logs kept, and are customer-relevant logs available to you?
- What is the commitment for notifying you of an incident, and is the plan tested?
Resilience
- What are the recovery time and recovery point objectives, and when were they last tested?
Subprocessors
- Is there a list of subprocessors, and are security obligations passed down to them?
Scoring
Rate each area Meets, Partially meets, Does not meet or Not applicable. Record the evidence reviewed. Every gap gets a condition, an owner and a due date before approval.
