
If a policy says something the business cannot actually do, people quickly learn to ignore it. That does not mean policies are pointless. It means they need to describe decisions your team understands, can follow, and knows how to question when the situation changes.
A cybersecurity policy sets expectations: who is responsible, what is allowed, how exceptions are handled, and when an issue should be raised. RIKR starts with a baseline and best practices, then considers the company using them. “Our way or the highway” is not a useful substitute for understanding the work.
Begin with the decisions you keep having to make
Can an employee use a personal computer? Who approves a new cloud application? Where do shared passwords belong? What should happen when someone reports a suspicious message? Those are good candidates for clear rules because uncertainty already costs people time.
A policy does not need to contain every technical setting. Keep the expectation understandable, then maintain procedures that explain how it is carried out. Name the person who approves the policy and the person who keeps the operational steps current. That separation makes it easier to change a tool without rewriting the business’s intentions.
Cover the areas that match your business
- Account and access expectations, including administrators, MFA, and employee changes.
- Acceptable use, approved applications, and handling of business information.
- Device management, updates, and responsibility for lost or stolen equipment.
- Backup, retention, and recovery responsibilities.
- Incident reporting, escalation, and communication approval.
- Supplier access and the process for reviewing exceptions.
These are starting topics, not a promise that six documents satisfy your obligations. Customer contracts, insurance conditions, applicable law, and the information you handle can add requirements. Have the right advisers interpret those obligations. Then check that the implemented process matches what the policy says.
Make exceptions visible
A specialist application may not support a preferred sign-in method. A contractor may need access for a limited project. Document the reason for an exception, the person accepting the risk, any temporary controls, and the review date. An exception without a review can quietly become the permanent rule.
NIST CSF 2.0 places strategy, policy, responsibility, and oversight within the Govern function. That is a useful reminder that security decisions belong with business decisions. IT should explain the options and consequences; leadership should understand what is being accepted and what is still being improved.
Source: NIST CSF 2.0, Govern function
Explain the rules where the work happens
A short onboarding conversation, a usable reporting route, and a reminder during an actual process can do more than asking employees to acknowledge a long document once a year. Make it safe to ask questions. If people repeatedly misunderstand the same instruction, review the instruction as well as the training.
RIKR can provide baseline cybersecurity policies upon request. They are a starting point for discussion and adaptation, not a certification or legal opinion. The goal is guidance your company can use, with technical controls and responsibilities that support it.
You should be able to ask why a rule exists and what problem it is meant to solve. The answer should connect to your business, not just to a template somebody downloaded.
Related: a business owner’s guide to NIST CSF 2.0
Explore RIKR managed cybersecurity
Written by Joshua Price
Back to the blog
