Security Policy Development in Rwanda
Written security policies your staff can actually follow, not a document that sits unread.
Security policy development produces the short, specific written rules your staff need to work securely, matched to your actual systems and ways of working. Any organisation without documented security expectations, or with policies copied from a template that nobody follows, needs it. This page covers security policies as part of putting controls in place. For a broader set of IT governance policies, written as part of an independent advisory engagement, see IT policy development under IT Consultancy.
What is security policy development, and who needs it
It’s the drafting, review and rollout of practical policies such as acceptable use, passwords and multi-factor authentication, access management, data handling, backup and incident reporting. Each policy is written in plain language for the people who must follow it, and backed by technical controls wherever possible, so the policy describes how systems actually behave. It suits organisations preparing for an audit, donor review or regulator visit, and any organisation whose security rules exist only in a few people’s heads.
The problem it solves
Unwritten rules disappear when the people who hold them leave. Over-long templates get filed and ignored. Policies that contradict how systems actually work teach staff that rules don’t matter. Good policies sit in the middle: short enough to read, specific enough to act on, and true to how things really work. They also give you a defensible answer when a funder, auditor or regulator asks how security and personal data are managed.
Policies and the law
Rwanda’s data protection law expects organisations that process personal data to protect it with appropriate measures, keep records of their processing activities, and report breaches to the National Cyber Security Authority within 48 hours. Policies are how those expectations become everyday practice: who may access personal data, how long it’s kept, how it’s shared, and what staff do when they suspect a breach. Institutions supervised by the National Bank of Rwanda also need documented security policies under its cybersecurity regulation.
We write policies that support compliance, but we’re not lawyers. Where a policy has legal or employment consequences, we flag it for review by your legal or HR adviser.
What makes a policy get followed
- Short. A page or two per policy, with the rules first and the reasoning after.
- Specific. Your actual systems, by name, rather than “the organisation’s information assets”.
- Backed by controls. If the policy says multi-factor authentication is required, the system enforces it.
- Owned. Each policy names a responsible person and a review date.
- Communicated. Staff read it, ideally with a short briefing, and acknowledge it.
An example: a password and sign-in policy on one page
To show the level of detail we aim for, a typical one-page policy might say: every account uses a passphrase of at least four words, never reused from another site; multi-factor authentication is required for email, files and every business system; passwords are never shared, sent by message or written on desks; administrator accounts are separate from everyday ones; and a suspected compromise is reported immediately to a named person, with no blame for reporting. Each rule matches a setting we configure, so the policy and the system say the same thing.
What the work involves
- Discovery. We find out how security works today, formally and informally, through interviews and a light technical review.
- Prioritise the policies that close your biggest gaps.
- Draft in plain language, specific to your systems.
- Review with management, IT and HR, adjusting rules that wouldn’t work in practice.
- Roll out: a short staff briefing, an acknowledgement process and a review calendar.
What’s included and what’s not
Included: policy drafting across the agreed areas, a review session with your team, and a staff briefing.
Not included: legal review of policies with binding employment or regulatory implications — we recommend this separately where relevant, since we’re not providing legal advice.
Typical timelines and what drives cost
An initial policy set for a single organisation typically takes one to two weeks, including review cycles. Cost is driven by the number of policies, how much discovery is needed, the number of sites and departments involved, and any specific frameworks the policies must align with, such as a regulator’s requirements or a donor’s conditions.
Common mistakes we see
Policies copied from an online template, referencing systems, laws or job titles that don’t exist in your organisation. Policies written but never shared with staff. Policies that describe an ideal nobody follows, which is worse than no policy because it creates false assurance. No owner and no review date, so the policy slowly goes out of date. And policies that require things the technology doesn’t enforce, which staff quickly learn to ignore.
.Bty1UFki_Z12ApNG.webp)
Cybersecurity
Related services
-
Security Monitoring
Continuous monitoring for the signs of intrusion that a firewall alone won’t catch.
-
Cybersecurity Assessment
A structured review of your current exposure, ranked by real risk rather than a generic checklist.
-
Network Security
Segmentation, monitoring and controls that stop a single compromised device becoming a network-wide breach.
Insights
Related reading
-
.DwIvkzVM_17wdD.webp)
, 4 min read
How Much Does IT Security Policy Development Cost in Rwanda?
Security policy development cost depends on policy scope, organisational input needed, and enforceability — here's what drives the number.
-
.Bx_vtB0H_Z1Cakp8.webp)
, 5 min read
IT Security in Rwanda: A Starting Point for Non-Technical Owners
IT security doesn't need to be understood in technical depth to be taken seriously — here's a plain-language starting point for a non-technical owner.
Frequently asked questions
Do we actually need written policies if our team is small?
Yes, arguably more so. In a small team, security practices usually live as unwritten habits held by one or two people, and they disappear when those people are away or leave. A written policy makes expectations explicit and lasting, gives new staff something to learn from, and gives you evidence for a funder, insurer, auditor or regulator that security is being managed deliberately.
Won't a generic policy template save time?
It saves drafting time, but usually costs compliance. A template written for a large corporation contains sections that don't apply, terms nobody uses and rules that contradict how work is actually done, so staff ignore it. A shorter policy written around your real systems and ways of working gets read and followed, which is the only reason to have one.
What policies matter most to start with?
For most organisations: acceptable use; passwords and multi-factor authentication; access, covering joiners, movers and leavers; data handling, covering what's sensitive and how to treat it; backup; and incident reporting, so staff know what to do when something looks wrong. That set closes the most common gaps we find. More specialised policies follow as the organisation and its risks grow.
Do policies need legal review?
Some do. Policies with employment consequences, such as monitoring staff email or disciplinary rules, or with regulatory implications, such as personal data handling, should be reviewed by a lawyer or your HR adviser. We write them as clear, practical documents reflecting good security practice and the technical controls in place, and flag the sections that need legal review.
How often should security policies be reviewed?
At least once a year, and whenever something significant changes: a new system, a move to the cloud, new regulation, or an incident that exposed a gap. Each policy should name an owner and a review date. A policy that describes systems you no longer use, or rules nobody follows, is worse than useless, because it gives false assurance.
Not sure where your real exposure is?
Start with an assessment. We’ll show you which gaps matter most before you spend on anything.