Certificate Topics — Building and Managing a Cybersecurity Program (Year 1 Foundations)

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) Presented by: Minister Destiny Marie Morgan, Muslim Ordained 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 only in your own browser on this device — the school collects and keeps nothing. 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 program; 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 — program structure, risk, and review — in this school's own words.

The lesson

Part 1. Program, Project, Tool — Three Different Things

A program is the ongoing way an organization 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 program 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 program; they are never the program itself. An organization that buys tools without a program 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 program. The program — 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 organization 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 program'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 organization accepts some risk, because fixing everything at once is impossible. The difference between a program 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

Programs 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 program 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 program 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 program 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 organized 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 organizations. Maturity is not a grade to brag about; it is a map. It tells you the honest next step for an organization of your size, instead of copying a corporation's program that would collapse under its own weight here.

The program 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 program reviewed four times a year will, within two years, protect an organization better than an impressive binder nobody opens.

Words to know — Building and Managing a Cybersecurity Program

• Cybersecurity program — The ongoing system of policies, people, routines, and reviews an organization uses to manage security over time.
• Asset inventory — A current list of systems, devices, data, and services an organization 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 organized 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 program. Fact: A product is one tool. Without an inventory, a risk register, owners, and reviews, there is no program — only software.
• Myth: A program is only for large organizations. Fact: Small organizations 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 program 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 program 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:

1. Start with Part 2: without an inventory, nobody can say what the tool would even monitor — list systems, data, accounts, and vendors first.
2. 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.
3. Use Part 4: name an owner for access reviews and for incident decisions before any emergency forces the question.
4. 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.
5. 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 program, 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 program 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 organizations.
• CISA Cyber Essentials (cisa.gov) — Free starter practices for small organizations 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 organizations.
• NIST Small Business Cybersecurity Corner (nist.gov) — Practical, free guidance written for organizations 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 program 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 Muslim Ordained Minister Destiny Marie Morgan

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 program 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 program structure used throughout.
• CISA Cyber Essentials — Cybersecurity and Infrastructure Security Agency (cisa.gov) — starter practices for small organizations.
• NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program — NIST (csrc.nist.gov) — program lifecycle thinking applied to people and routines.

Your Progress — On Your Device Only — Building and Managing a Cybersecurity Program

• Learning outcomes: On completing this unit, the student can:
• Distinguish a program 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 program 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 program 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 only in your own browser on this device, 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).