Session 8: Policies, Risk & Final Project

Most security policies fail because they are written to be impressive rather than usable: twenty pages nobody reads, requiring behaviour that makes the job harder, and enforced by nobody. A policy that is followed is short, specific, and costs people almost nothing. For a small business, one page covering five things outperforms a handbook covering fifty.

The five that matter: passwords and accounts — a password manager is provided and required, passwords are never shared or written down, and two-factor is on for every business account. Devices — every laptop and phone is locked and encrypted, and a lost or stolen device is reported immediately. Data — backups run automatically and nobody stores business data only on their own machine. Messages — no one-time code is ever shared with anyone, and any request for payment is verified through a second channel. Reporting — if something seems wrong, say so immediately and there will be no blame.

That last point deserves emphasis, because it is the one organisations get wrong. If staff fear being told off for clicking a link, they hide it, and a hidden incident becomes a large one. A no-blame reporting culture is a security control, and it is free. The policy should say so explicitly, because otherwise nobody believes it.

The assessment follows the model from session one and produces something a business can act on. List the assets — what would genuinely hurt to lose or expose: customer data, the bank account, the social accounts, the order records, the ability to trade. Apply the CIA triad to each, because it turns vague worry into a specific question.

Then identify the vulnerabilities in this specific setup, not generic threats: no backup, one shared password, an unencrypted laptop, a router on its default admin password, no two-factor, software installed from a pirated source, a staff member who is the only person who knows the passwords. These are findable by looking, and they are what you can act on.

Score each on likelihood and impact — a simple high, medium, low is sufficient and more honest than a false numeric precision. Rank them, and then recommend controls in order of risk reduced per naira, which for almost every small business means backups, two-factor, a password manager, updates, device encryption, and staff awareness, in that order. Include what you would deliberately not spend on, because that is as valuable as what you recommend.

A security review is a document, and its quality determines whether anything changes. The structure that works: an executive summary of one paragraph in plain language, stating the overall position and the top three actions — because the owner will read this and possibly nothing else. Then the scope, so it is clear what was and was not examined. Then the findings, each with what it is, why it matters in this business's terms, and how to fix it. Then the prioritised recommendations with cost and effort. And finally what was not covered.

Two habits make the difference. Write every finding in the business's terms, not in technical ones: not 'the router uses default credentials' but 'anyone who knows your router model can take control of your internet connection and see where your staff go online'. And give each finding a clear fix with a cost, because a problem without a solution is just a worry, and a business owner who cannot act on it will set the report down.

Be honest about the limits of what you did. A review is not a penetration test and does not prove anything is unbreakable; it identifies the exposures that matter and the order to fix them. Saying so protects you and it is what a professional does. Overclaiming — 'your systems are now secure' — is both false and a liability waiting to arrive.

The conversation matters as much as the document. Lead with the business consequence, not the technical fault: 'if this laptop is stolen today, every customer record on it goes with it, and there is no copy' lands where 'the disk is unencrypted' does not. Then give the fix and its cost, and let them decide.

Avoid fear as a sales technique. A frightened client makes bad decisions, buys the wrong things, and resents you later. The honest framing is that most risks are ordinary and most fixes are cheap, and that doing the five basics puts them ahead of nearly every comparable business. That is true, it is reassuring, and it is more likely to produce action than a threat.

And be willing to say 'you do not need this'. Declining to sell a control that does not reduce their actual risk is the fastest way to be trusted with everything else, and in a market where everyone knows everyone, that trust is the entire business.

The honest position after four weeks: you can assess a small business's security, apply the controls that matter, respond to the common incidents, and explain all of it to someone with no technical background. That is genuinely employable and genuinely useful, and it is more than most small businesses in this market have ever had done.

The natural next steps branch. Security operations and monitoring — watching for and triaging alerts — is where most entry-level jobs sit. Governance, risk and compliance is document and process work, largely non-technical, and it is a large and steady employment area. Technical specialisms such as penetration testing need deeper networking and scripting skill, which you can build on top of this. And IT support is the most common entry route into security in practice, because it teaches you how systems actually fail.

Certifications help once you have the grounding — CompTIA Security+ is the usual first one and it maps closely to what this course covered — but they certify knowledge you already have rather than supplying it. What actually gets you hired is being able to look at a real setup, name what is wrong with it in plain language, and fix the things that matter in the right order. That is what the final project demonstrates.