Skip to content
HUMANWALL

Mission 22

Cybersecurity Policies, Governance and Responsibilities

Telling staff to ‘be secure’ is not a policy. This mission helps owners and managers write short, usable rules, give each one a named owner, make clear who decides what, and keep it all current with a simple review cycle.

14 minutesResilience ChampionJump to scenario & quiz ↓

In this mission you will

  • Explain what turns a policy from a document into something people actually follow.
  • Write a short, practical policy with a named owner, clear rules and a way to communicate it.
  • Map key security decisions to people using a simple RACI-style table.
  • Set up a review cycle and a safe process for approving exceptions.

Why small businesses need policies at all

In a small team, many decisions live in the owner’s head. That works until the owner is travelling, a new person joins, or something goes wrong at 9 pm on a Saturday. A policy is simply an agreed answer to ‘What do we do here?’, written down so that everyone gets the same answer. Good policies reduce arguments, speed up decisions and protect staff, because people can follow a known rule instead of guessing. Governance sounds formal, but for an MSME it just means: who decides, who does the work, and how we check it is happening.

Policy areas most small businesses need

  • Acceptable use: how business devices, email, WhatsApp and internet may be used.
  • Access: who gets which accounts, who approves, and how access is removed when people leave.
  • Data handling: where customer and business data may be stored and shared.
  • Software and devices: who approves new apps, and how updates are kept current.
  • Remote and mobile work: rules for working from home, cafés and personal phones.
  • Backups: what is backed up, how often, and who tests a restore.
  • Incident response: who to tell, how fast, and who decides next steps.
  • Supplier access and payment verification: how vendors get access, and how bank detail changes are confirmed.

Short beats perfect

A policy nobody reads protects nobody. For a small business, one page per area is often enough, and several areas can sit in a single short handbook. Write in plain language, using ‘we’ and ‘you’. Each rule should be something a person can do or check, such as ‘Any change to supplier bank details is confirmed by phone using the number in our records, and approved by a second person’. Avoid vague lines such as ‘Use strong security’ or ‘Be careful with data’. If a rule cannot be followed in practice, fix the rule or provide the tool that makes it possible.

What makes a policy operational

  1. 1Owner: one named person keeps the policy current and answers questions about it.
  2. 2Approval: the owner or senior manager formally agrees it, with a date and version.
  3. 3Communication: staff are told what changed, in the language and channel they actually use.
  4. 4Training: people are shown how to follow it, ideally with a real example from their work.
  5. 5Evidence: there is some simple sign that the rule is followed, such as a log or a periodic check.
  6. 6Review: it is revisited on a set cycle and after any significant change or incident.

Exceptions without loopholes

Sometimes a rule does not fit. A machine on the factory floor may run old software that cannot be updated, or a key client may insist on a particular file-sharing tool. Do not quietly ignore the policy. Record the exception: what rule is being set aside, why, who approved it, what extra safeguard reduces the risk, and when it will be reviewed or expire. An exception with an end date is a managed decision. An exception without one becomes a permanent hole.

Practical business example

Patel Auto Components replaces a slogan with owners

Patel Auto Components, a fictional 45-person parts maker in Rajkot, had a single poster on the wall: ‘Use strong security’. When a supervisor wanted a free PDF tool, nobody knew who could approve it. When a phone with the company email was lost, three people called the IT partner and nobody called the owner. The general manager, Hetal, sat with the owner and the IT partner for one afternoon. They chose five areas: access, software, backups, incidents and payments. For each, they wrote one page in Gujarati and English with five practical rules and a named owner. They made a small RACI table showing who approves software, who handles incidents and who is told. Hetal explained the rules in the monthly staff meeting and posted a summary in the staff WhatsApp group. Every six months, and after any incident, the owners review their page.

The lesson: Clarity, not length, made the difference. Named owners and a simple decision table turned a slogan into rules people could follow.

Key takeaways

  • A policy is an agreed answer to ‘What do we do here?’; keep it short, plain and practical.
  • Every policy needs one named owner, an approval date and a review date.
  • Use a simple RACI-style table so everyone knows who decides on software, access, incidents and payments.
  • Communicate rules in the language and channels your team actually uses, and show people how to follow them.
  • Manage exceptions openly, with a reason, approver, extra safeguard and expiry, and remember that approved policies do not mean the business is compliant or secure.

Scenario lab · +25 XP

Strong security, but who decides?

You are the operations manager at Sahyadri Travels, a fictional 25-person travel agency in Nashik. Staff have been told to ‘use strong security’. This week, a sales executive installed a browser extension to compare fares, and someone else forwarded a suspicious email to the whole team asking if it was real. Nobody knows who approves software or who handles possible incidents. The owner asks you to fix this.

Fictional scenario. Never enter real passwords, OTPs or customer details anywhere in this course.

Decision 1 of 3

What is your first step?

Knowledge check · +20 XP on mastery

Check your understanding

1. What makes a policy operational rather than just a document?
2. In a RACI table, how many people should be Accountable for a single decision?
3. A machine on the shop floor cannot be updated because its software is old. What is the best approach?
4. When should a security policy be reviewed?

Practical action · +40 XP (self-reported)

Write one usable policy page

Choose one policy area that causes confusion today and turn it into a short, owned rule set. Keep it general. Do not include passwords, account numbers or confidential details.

  1. 1.Pick one area, such as software approval, incident reporting or payment verification.
  2. 2.Name one owner who will keep it current and answer questions.
  3. 3.Write three to five practical rules that a person can actually follow and check.
  4. 4.Add a small RACI line: who is responsible, accountable, consulted and informed for the main decision.
  5. 5.Decide how you will communicate it, such as a staff meeting plus a summary in the team group, in the language staff prefer.
  6. 6.Set a review date six or twelve months from now, and note that it will also be reviewed after any incident.

Do this in your own records. Don’t enter passwords, OTPs, customer data or incident details here.

Mission status: Not started

A mission is complete when you have read the lesson, answered the knowledge check and acknowledged the practical action. Mastery means scoring at least 3 of 4 on the knowledge check.

View my progress