School: Minister Destiny Testimony Schools Track: Law Enforcement Class: Certificate Topics — Year 1 (Foundations) · Home: Schools — Law Enforcement track Certificate behind this topic: "Building and Managing a Cybersecurity Program" — LinkedIn Learning, earned by Minister Destiny Marie Morgan (May 29, 2025) Founded and presented by: Minister Destiny Marie Morgan, Minister
This lesson is educational information from Minister Destiny Testimony Schools. It teaches the public body of knowledge in this subject — the same ground Minister Destiny studied for her certificate — in this school's own words. It is not the original course, it does not award the original credential, and it is not legal or medical advice. If you are in danger right now, call 911. It is community-designed training, not agency policy, and school completion is a school achievement only — not a law-enforcement rank, title, or credential.
Before you start
- This school never asks your name. Your progress is saved to your student record, so you can pick up on any device. If you pass this unit's quiz (80% or higher, retakes allowed), you earn a downloadable certificate with a blank line — you write your own name on it after you save it. Quiz answers are not shown; if you miss a question, re-read the lesson and try again.
- This unit is for anyone who protects systems others depend on — a small agency, a nonprofit, a school office, or a business. You do not need a large budget to have a programme; you need an honest list of what you have, what could hurt it, and who owns each fix.
- Minister Destiny Marie Morgan earned the certificate behind this topic while building her own public platforms. This unit teaches the same public ground — programme structure, risk, and review — in this school's own words.
The lesson
Part 1. Programme, Project, Tool — Three Different Things
A programme is the ongoing way an organisation manages security over time: its policies, people, routines, and reviews, all pointed at the same goal. A project is a piece of work inside the programme with a start and an end — for example, rolling out multi-factor authentication this quarter. A tool is a product: an antivirus platform, a firewall, a password manager. Tools serve the programme; they are never the programme itself. An organisation that buys tools without a programme owns expensive software and still cannot answer basic questions: What do we protect first? Who decides? How do we know it is working?
Public frameworks make this distinction concrete. The NIST Cybersecurity Framework 2.0 (CSF), published free by the National Institute of Standards and Technology, describes outcomes — Govern, Identify, Protect, Detect, Respond, Recover — not products. Notice that Govern comes first: someone must own risk decisions before any tool is switched on. When you hear a vendor promise that one product 'solves security,' translate it honestly: it may solve one project inside your programme. The programme — the deciding, listing, checking, and improving — remains your job, and it never finishes.
Part 2. Start With What You Have — The Asset Inventory
You cannot protect what you have not listed. An asset inventory is a plain record of the things whose loss or compromise would hurt: computers and phones, servers and cloud accounts, the data on them (case records, personnel files, financial data), the people who can reach that data, and the services you depend on, including vendors. For each asset, note where it lives, who owns it, and how sensitive it is. A small organisation can start in a spreadsheet; completeness matters more than fancy software.
Inventories decay. People leave, laptops are replaced, a free cloud account someone opened for one project quietly becomes where files live. That is why the inventory belongs to the programme's review cycle (Part 6), not to a one-time spring cleaning. A practical habit: whenever something is bought, retired, or connected, the inventory changes the same week. In law-enforcement settings the stakes are plain — an unlisted device holding sensitive records is a risk nobody chose; it is a risk nobody saw.
Part 3. The Risk Register — Writing Risk Down Honestly
A risk register is a short, living list of the harms you can foresee, scored simply so you can order your work. For each risk, write four things: what could happen (for example, 'ransomware encrypts the shared drive'), how likely it is, how bad it would be, and what you are doing about it — plus the name of the person who owns that response. Likelihood times impact gives you a working priority. You do not need mathematics beyond that to make better decisions than guessing.
A register also records the risks you consciously accept. Every organisation accepts some risk, because fixing everything at once is impossible. The difference between a programme and wishful thinking is that accepted risks are written, dated, and revisited — not silently ignored. When leadership signs off on the register, they are signing for those choices. That honesty protects everyone later: after an incident, the question 'did we know?' has a documented, fair answer.
Part 4. People and Accountability — Roles Before Emergencies
Programmes fail quietly when 'security' is everyone's job in general and nobody's job in particular. Name the roles, even in a three-person office: who approves new software, who reviews access when someone changes jobs, who declares an incident and calls for help, who talks to the public. NIST CSF 2.0's Govern function exists for exactly this — roles, responsibilities, and oversight are security controls, not paperwork decoration.
Accountability also means access follows the job. Least privilege — each person can reach only what their work requires — is a programme decision enforced by routine reviews, not by suspicion of any individual. When someone leaves, access ends the same day; when someone moves teams, old access is removed before new access is added. Write these triggers into the programme so they happen on busy days too, because busy days are when they get skipped.
Part 5. Policies People Can Actually Follow, and a Budget That Matches
A policy is a short, plain statement of how things are done here: passwords and multi-factor authentication, how data is backed up, what may be installed, how incidents are reported. Good policies are few, readable in minutes, and possible to obey. A rule nobody can follow teaches staff to ignore all rules. Test each policy with one question: could a new employee do this correctly on their first Friday, with the tools we actually provide? If not, fix the policy or provide the tool.
Budget follows the register, not the sales pitch. Rank spending by the risk it reduces: backups and multi-factor authentication before exotic monitoring; patching discipline before new hardware. A small programme that funds its top three risks fully beats a large one that funds twelve risks thinly. Record why each purchase was chosen in the register — next year's budget conversation then starts from evidence, not memory.
Part 6. Maturity and the Review Cycle — Getting Better on Purpose
A maturity model describes, in plain stages, how organised your practices are: from ad hoc (heroics when something breaks), to repeatable (written routines), to measured (you track whether routines work), to improving (lessons change the routines). NIST publishes its framework freely, and CISA's free Cyber Essentials offer a starter view for small organisations. Maturity is not a grade to brag about; it is a map. It tells you the honest next step for an organisation of your size, instead of copying a corporation's programme that would collapse under its own weight here.
The programme runs on a review cycle: the inventory, register, policies, and access lists are re-examined on a schedule — quarterly for fast-moving items, at least yearly for all — and after every incident. Each review ends with a short list of changes, owners, and dates. That cycle is the whole secret. A modest programme reviewed four times a year will, within two years, protect an organisation better than an impressive binder nobody opens.
Words to know — Building and Managing a Cybersecurity Program
- Cybersecurity programme — The ongoing system of policies, people, routines, and reviews an organisation uses to manage security over time.
- Asset inventory — A current list of systems, devices, data, and services an organisation depends on, with owners and sensitivity noted.
- Risk register — A living list of foreseeable harms with likelihood, impact, planned responses, accepted risks, and a named owner for each.
- Least privilege — Giving each person access only to what their job requires, and removing access when the job changes or ends.
- Maturity model — A plain-language scale describing how organised security practices are, from ad hoc to measured and improving.
- Review cycle — The scheduled re-examination of the inventory, register, policies, and access, ending in assigned changes.
- Govern (NIST CSF) — The CSF 2.0 function covering ownership, roles, risk decisions, and oversight — the foundation the other functions rest on.
- Control — A specific safeguard or practice that reduces a risk, such as multi-factor authentication or tested backups.
- Incident — An event that harms, or could harm, the confidentiality, integrity, or availability of systems or data.
Myths vs facts — Building and Managing a Cybersecurity Program
- Myth: Buying a strong security product gives us a programme. Fact: A product is one tool. Without an inventory, a risk register, owners, and reviews, there is no programme — only software.
- Myth: A programme is only for large organisations. Fact: Small organisations need the same thinking at smaller scale: a spreadsheet inventory and a one-page register are a real start.
- Myth: Once we write the policies, we are done. Fact: Policies age as people, tools, and threats change. The review cycle, not the writing day, is what keeps a programme alive.
- Myth: Maturity means reaching the highest level as fast as possible. Fact: Maturity is a map for choosing the honest next step that fits your size and risk — not a race or a bragging grade.
- Myth: If nothing bad has happened, our programme must be fine. Fact: Quiet can mean luck. Only inventories, tests, and reviews show whether protection would actually work on a bad day.
Think it through — Building and Managing a Cybersecurity Program
A small county office holds sensitive records on a shared drive. There is no asset inventory; a former employee's account is still active; backups exist but have never been tested; and leadership just approved buying an expensive monitoring tool a salesperson recommended. The office asks you: 'Are we secure now?'
Walk it through:
- Start with Part 2: without an inventory, nobody can say what the tool would even monitor — list systems, data, accounts, and vendors first.
- Apply Part 3: build a short risk register. The still-active former employee account and untested backups will outrank almost everything; both are cheap to fix.
- Use Part 4: name an owner for access reviews and for incident decisions before any emergency forces the question.
- Apply Part 5 to the purchase: budget follows the register. Fund backups testing and multi-factor authentication first; the monitoring tool may come later, justified by a named risk.
- Close with Part 6: set a quarterly review so the inventory, register, and access list stay true. The honest answer to leadership is: not yet — but now there is a programme, and a dated plan.
Try this — Building and Managing a Cybersecurity Program
- ☐ Start an asset inventory: list every device, cloud account, and data store your team uses, with an owner for each
- ☐ Open a risk register with your top five foreseeable harms, each with likelihood, impact, and a named owner
- ☐ Check for accounts belonging to people who have left, and close or transfer them this week
- ☐ Pick one policy and test it: could a new person follow it correctly with the tools you actually provide?
- ☐ Put a quarterly programme review date on the calendar now, with the inventory and register on its agenda
Resources to keep — Building and Managing a Cybersecurity Program
- NIST Cybersecurity Framework (CSF 2.0) (nist.gov) — The free framework this unit is built on — Govern, Identify, Protect, Detect, Respond, Recover — with quick-start guides for small organisations.
- CISA Cyber Essentials (cisa.gov) — Free starter practices for small organisations and local agencies, in plain language.
- CISA — Cybersecurity resources and alerts (cisa.gov) — Current advisories, ransomware guidance, and free services for public-sector and small organisations.
- NIST Small Business Cybersecurity Corner (nist.gov) — Practical, free guidance written for organisations without a security department.
What you earned / what's next — Building and Managing a Cybersecurity Program
✅ Building and Managing a Cybersecurity Program complete (quiz score 80% or higher): You can explain what a cybersecurity programme contains, start an asset inventory and risk register, assign clear ownership, and run a review cycle that improves security on purpose.
Your certificate
Minister Destiny Testimony Schools Certificate of Completion — Building and Managing a Cybersecurity Program
This certificate is presented by Minister Destiny Marie Morgan, Minister
Awarded to: ______________________________ (write your name here after you download — your name is never collected or stored by this school)
Date completed: ______________
Congratulations. You now think like a programme builder — list what you protect, write the risks down honestly, give every fix an owner, and review it all on schedule. That steady habit protects people far more than any single product ever will. — Minister Destiny Marie Morgan
This is a certificate of educational completion from Minister Destiny Testimony Schools. It is not a state license, a government certification, or the original course credential. School rank and completion are school achievements only — not a law-enforcement rank, title, or credential.
What's next: Return to the Certificate Topics for your next Year 1 Foundations topic.
Sources
- NIST Cybersecurity Framework 2.0 — National Institute of Standards and Technology (nist.gov) — the six functions, Govern first, and programme structure used throughout.
- CISA Cyber Essentials — Cybersecurity and Infrastructure Security Agency (cisa.gov) — starter practices for small organisations.
- NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program — NIST (csrc.nist.gov) — programme lifecycle thinking applied to people and routines.
Course Record — Building and Managing a Cybersecurity Program
- Learning outcomes: On completing this unit, the student can:
- Distinguish a programme from a project and from a tool, and explain why tools alone do not create security
- Build the first version of an asset inventory with owners and sensitivity noted
- Write risk-register entries with likelihood, impact, a planned response, and a named owner
- Assign the core programme roles and apply least privilege to access decisions
- Rank a security budget by the risks it reduces rather than by sales pressure
- Describe maturity in plain stages and run a scheduled programme review cycle
- Study time: Approximately 1 hours — an estimate covering reading, activities, and the test. Students move at their own pace.
- Assessment: A 10-question test drawn only from this unit's lesson. 80% or higher passes and earns the unit certificate. Answers are not shown; your score is saved to your student record, and retakes are allowed.
- Level: Certificate Topics — Year 1 (Foundations) · Law Enforcement school · working rank on completion path: Freshman → Sophomore.
- Version: Version 1.0 — October 2026.
Minister Destiny Testimony Schools — Law Enforcement. Educational information only. Help lines: 911 for emergencies · 988 Suicide & Crisis Lifeline (call/text 988).