A computer security policy tells people what they must do, who owns the work and how exceptions are handled. Begin with the systems that keep your team operating, then write requirements the team can actually implement and check.
This guide is for a small organization with ordinary business devices and online services. Gather an account and device inventory, a list of important data, the people responsible for IT and the obligations in your contracts. Sector rules and legal duties require their own review.
Define the policy’s boundaries
Name the devices, accounts, services, workers and contractors covered. Include personally owned devices that access business information, or explicitly define an approved alternative. State who approves the policy and who maintains the supporting procedures.
The NIST small-business quick-start guides provide a way to organize priorities across governance, assets, protection, detection, response and recovery. Use that structure to find gaps. A completed template alone does not establish compliance or prove the controls operate.
Keep three items distinct: the policy states the requirement; a procedure gives the steps for a particular service; a record shows what happened. “Former workers lose access at the approved departure time” is a policy. A provider-specific checklist is the procedure. A completed access-removal ticket is the record.
Write requirements with owners and evidence
| Area | Requirement to adapt | Owner and evidence |
|---|---|---|
| Accounts | Use individual accounts, approved sign-in methods and role-appropriate access. | System owner: approved access request and periodic review. |
| Devices and updates | Use supported software and a managed update process; record exceptions and compensating measures. | IT owner: device inventory and update report. |
| Data and backups | Store business records in approved locations; define retention and test recovery. | Data owner: restore record with files and result. |
| Remote work | Use approved remote access and report a lost device through the designated channel. | IT owner: remote-access configuration and staff instructions. |
| Incidents | Report suspicious activity promptly and preserve relevant details. | Incident lead: reachable contact route and incident log. |
| Departures | Remove access, transfer ownership and retrieve managed equipment at the approved time. | Manager and IT: completed departure checklist. |
Replace broad phrases such as “regularly update” with an agreed schedule, a method for prioritizing urgent exposures and an escalation owner. Set deadlines from the actual risk and your ability to act. Document how unsupported equipment is isolated, replaced or otherwise addressed.
Make the sign-in rule specific
Provide an approved password manager and require unique credentials where passwords are used. Identify accounts that must use multifactor authentication and which methods are supported. Prefer phishing-resistant options when feasible, especially for administrative and email accounts. The passcode and passkey guide explains the tradeoffs.
For organizations implementing authentication systems, NIST SP 800-63B-4 distinguishes single-factor password requirements from passwords used with MFA, and discourages arbitrary periodic password changes absent evidence of compromise. Apply the relevant requirements in context; this federal digital-identity guideline is not a blanket certification for a small business.
Specify how a help desk verifies a recovery request. An urgent call from someone claiming to be the owner still needs the approved verification process. Document a protected emergency-access route and test it without exposing recovery secrets in the policy document.
Give exceptions an owner and an end date
An exception record should include the affected asset, the requirement it cannot meet, the business reason, the exposure, interim safeguards, an approver and an expiry or review date. The approver accepts a defined risk; they do not simply waive the need to understand it.
This example supplies a decision process, not an automatic justification for delaying security fixes. An actively exploited vulnerability may require a different immediate response, including taking an exposed service out of use.
Roll out the policy as a working process
- Fill the blanks with the people doing the work. Confirm who can configure the controls and who can authorize spending or disruption.
- Try the procedures. Test an approved account setup, a sample restore and a departure using a test account. Resolve failures before promising the behavior.
- Publish a short staff version. Tell staff where to store files, how to sign in, how to get help and what to report. Keep administrative procedures accessible to their owners.
- Review evidence. Sample real records at an agreed cadence and after major changes. A missing log or unreachable responder is a specific improvement item.
The editable template includes an adoption checklist and exception record. Fill every bracketed field, remove inapplicable options and attach service-specific procedures. Use identity management for access changes and the managed-service guide when responsibilities cross a supplier boundary.