By Onyekachi Fortune Okereke

Earlier this month, I had the privilege of speaking at Kennesaw State University’s Cyber Speaker Series, where I delivered a talk titled “Building a Cybersecurity Program from Scratch: Real Life Lessons.”

It was a lively session with students and faculty, where we unpacked how organizations can move from “zero” to a functioning security program, with practical lessons I’ve lived through in the field. We talked about the realities of being the first security hire, how to prioritize when everything feels urgent, and why third-party risk management is no longer optional. 

If you’d like to watch the full talk, the university has published the recording here:

👉 Watch the full talk on KSU MediaSpace

This article expands on that talk; following the flow of my slides but adding more detail, stories, and takeaways for anyone who may one day find themselves building a security program from the ground up.

What Exactly is a Security Program?

A security program is not a single tool, project, or hire. It’s the structured set of people, processes, and technologies that work together to identify, manage, and reduce cybersecurity risks.

Without a program, security becomes random and reactive. For example:

• A ransomware scare → company rushes to buy endpoint protection.

• A phishing incident → MFA rolled out in a hurry.

• A compliance deadline → policies are written overnight.

These are all useful controls, but when applied without structure, they don’t add up to resilience. A program ensures security is intentional, proactive, and aligned with business goals.

And Why Would You Be in a Scenario to Build from Scratch?

Most security professionals will join organizations that already have something in place: a handful of controls, a few policies, maybe even a dedicated team. But what if you don’t?

There are very real situations where you may be asked to build a cybersecurity program from the ground up:

• You join a startup as the first security hire. The company has focused on product and growth first, and is only now realizing it needs security.

• You become a CISO at a mid-size company and discover that security has been an afterthought. Suddenly, you’re charged with putting structure in place quickly.

• A compliance requirement, customer demand, or near-miss incident forces leadership to act, and you’re the one tasked with starting from square one.

This happens more often than people think. Many startups and growing companies only begin to prioritize security after scaling, when the risks become impossible to ignore.

And when you do find yourself in this situation, you’ll face an immediate question: “Where do I even begin?”

That’s where the challenge of different perspectives comes in, which we’ll explore next.

Everyone Starts From Their Own Perspective

When faced with a blank slate, different security specialists would prioritize different starting points. For example:

• SecOps analyst → “We need monitoring first (let’s buy a SIEM)”.

• AppSec/pentester → “We should start testing applications.”

• Governance lead → “We must draft policies right away.”

• Compliance officer → “Let’s check regulatory requirements first.”

• Network/cloud engineer → “Firewalls, segmentation, and cloud configs come first.”

Each of these perspectives is valid, but not all of them are the right starting point.

It’s like five contractors standing over a house plan. The electrician says wiring must go perfectly but doesn’t care too much about the foundation, the plumber focuses on piping, the roofer wants to secure the top before rain, while the carpenter demands framing. Each is right in their own way - but if everyone builds in isolation, the house will never be livable.

Let’s imagine what happens if we follow just one perspective:

Take the SecOps path. In an organization with no security program, you buy a SIEM as the first security effort, spend months configuring log sources, alerts start firing - but then you realize there are no policies defining who responds. The company hasn’t even mapped its crown jewels, so you don’t know which alerts matter most.

Or if we followed only the Compliance officer’s path, we’d draft a dozen policies that sit unused while attackers exploit unmonitored systems. Without risk assessment or governance, you end up drowning in data without clarity.

That’s why building from one lens, no matter how valid, rarely works.

How Do We Prioritize? Where Do You Start?

The answer is simple: start with risk.

Risk-based prioritization keeps everyone grounded. It ensures that, instead of following personal preferences, the program focuses on what matters most to the business.

Here’s what to do first if you find yourself in the situation where you need to build a new security program:

• Learn the business first. A security leader who doesn’t understand what drives revenue is flying blind. For example, in fintech, uptime and availability may matter more than anything else. In healthcare, protecting patient data is paramount. Context decides priority.

• Identify the crown jewels. These are the assets, systems, and processes that, if compromised, would cause the most damage. For one company it might be a customer database; for a bank, it may be the core-banking system. Mapping systems to business impact is the first step to making security meaningful.

• Assess likely threats. Not all risks are equal. A manufacturing company may be more exposed to ransomware disrupting operations, while a government agency might be more concerned with insider threats. Focus on what’s most realistic for your environment.

• Focus on outcomes, not tools. Don’t just say “deploy SIEM.” Say “detect unauthorized access within 15 minutes.” Outcomes make it clear why a control matters, and leadership will care more about measurable results than brand names.

Prioritization is what turns a collection of controls into a real program. Just like a house needs a foundation before walls, your security program needs risk awareness before tooling.

What about Security Frameworks?

Frameworks (like NIST CSF, ISO/IEC 27001, and CIS Critical Security Controls) are often the first thing people think of when starting a security program. And for good reason:

• They provide a blueprint for security programs.

• They help avoid reinventing the wheel.

• They ensure coverage across people, process, and technology.

• They lend credibility with regulators, auditors, and customers.

But used poorly, they become expensive checklists. Organizations spend months “implementing controls” without asking whether those controls address their real risks.

This is where tailoring comes in. 

ISO 27001, for example, includes the Statement of Applicability (SOA) - a document in which you map what controls apply to your environment, which don’t, and why.

Imagine a cloud-native, remote-only SaaS company. ISO 27001 includes physical security controls like CCTV monitoring and physical server protection. Such a company with no data centers or physical offices could mark ISO 27001's physical security controls as “Not Applicable” in the SOA, documenting that its infrastructure is entirely cloud-hosted - essentially allowing it to avoid implementing irrelevant controls.

The lesson: Frameworks should not replace risk assessment (most even encourage it), and the best way to use frameworks is to adopt only clauses or controls which would be relevant to the business context and risks.

Getting Buy-In Without Scaring People

One of the best ways to build buy-in is to avoid coming across as the department of “No.” Security should be seen as an enabler, not a blocker.

I experienced this first-hand once when our sales team added iframes to the company product to allow them demo customer integrations. From a security perspective, this raised red flags and normally, we would enforce X-Frame-Options headers to prevent clickjacking (meaning no iframes allowed).

The wrong approach would have been: “Absolutely not. Take this down immediately.” That creates friction and frames security as an obstacle.

Instead, we took a collaborative angle: “Let’s discuss how we can secure this sales implementation together.”

In the end, we did disable iframes on our product, but because of how the conversation was framed, the sales team saw security as a partner helping them succeed, not an enemy shutting them down. That shift in tone is what creates real buy-in.

Generally, you should:

• Frame security as empowerment. “With MFA, your account is harder to hack” is more relatable than “hackers are everywhere!!!!!”

• Translate risks into business language. Instead of “SQL injection,” say “this could expose thousands of customer records.”

• Focus on shared responsibility. Security isn’t “us vs them.” It’s everyone locking the same door together.

• Celebrate small wins. When phishing simulations improve, for example, make it known.

Getting Buy-In from Senior Management & the Board

Executives think in terms of risk, cost, and outcomes. If you come with technical jargon, you may lose them. But talk about dollars and customer trust - and now you have their attention.

For example, during one interaction I had with Execs, where I highlighted the risk of Account Takeovers (ATO). Instead of saying, “Attackers could brute force logins,” we explained in the following way:

• Each Account Takeover (ATO) could cost the company thousands of dollars to investigate and remediate.

• At scale, if just 10 accounts were compromised, settlement and customer restitution could run into millions.

• Beyond money, customer trust loss could have long-term brand impact.

• We can spend just $20,000 to implement controls which would minimize the risk of ATO materializing.

We presented this as: “Investing in stronger authentication now could save us millions in the event of an attack.” Framing it this way turned a technical vulnerability into a clear business risk they couldn’t ignore.

Your goal isn’t to make them experts. It’s to make them care enough to invest.

Quick Wins that Build Momentum

Here’s an important nuance: quick wins aren’t about replacing risk assessments. You should still start building your security program with risk. But while risk assessments may take time to complete, you can deliver early wins in parallel.

These show progress, build credibility, and buy you time for bigger initiatives. Examples of some quick wins are:

• Implement MFA. No matter your risk profile, MFA reduces credential theft. Rolling this out early proves you’re serious and gets quick visibility.

• Run phishing awareness campaigns. A simple simulated exercise helps employees learn and provides measurable improvement.

• Patch critical systems. Quick vulnerability sweeps and patches address low-hanging fruits attackers look for.

• Introduce secure email gateways or filtering. Email remains the top attack vector, and improvements here are felt immediately by staff.

• Enable logging and monitoring. Even basic central logging makes troubleshooting and detection easier. It gives you visibility while you’re still maturing.

These are like installing smoke detectors while designing the house. You’re still drafting the blueprints (risk assessment), but there’s no reason not to put in obvious safeguards now.

Common Roadblocks

That said, you will run into roadblocks when you want to introduce security controls to an organisation that has operated for years without them.. Here are some classic roadblocks you may hit, with scenarios:

• Budget constraints. Leadership says, “We want security, but can you do it with zero headcount increase?” — leaving you juggling unrealistic expectations.

• Culture pushback. Employees complain: “Why do we need MFA? It slows us down.” Suddenly you’re fighting perception, not just risk.

• Shiny object syndrome. A VP returns from a conference and insists, “We must buy this AI-powered tool.” Now you’re pressured to spend a budget on tech that doesn’t fit the roadmap.

• Competing priorities. The IT team says, “We can’t prioritize patching, we’re in the middle of a product launch.” Security slips because business goals win.

• Overpromising. A new CISO promises the board “zero breaches” in 12 months. That sets the entire team up for failure and distrust.

Recognizing these scenarios early helps you set expectations and craft responses before they derail progress.

Lessons I Learned

Building from scratch multiple times has taught me lessons that frameworks alone don’t cover, and I have even gotten better in navigating the roadblocks above.

• Security is a journey, not a project. The finish line doesn’t exist. Programs evolve with the business.

• Don’t try to do everything at once. I’ve seen leaders burn out teams by chasing 15 initiatives in parallel. Sequencing matters more than speed.

• Relationships matter. Some of the biggest security wins I’ve achieved weren’t technical - they came from strong relationships with HR, Legal, IT, and Finance. Sometimes, having security champions in different teams takes away most of the stress in your job.

• Communicate constantly. Silence breeds doubt. Even small updates like “We rolled out MFA to 20% of staff this week” builds confidence. Consider a short security newsletter for senior management as the pros of constant communication far outway whatever stress is required for it.

• Celebrate resilience. When incidents happen (and they will), highlight the recovery. “We contained the phishing attempt within 30 minutes” is as important as prevention.

But Don’t Forget Third-Party Risk Management (TPRM)

Third-party risk is one of the biggest blind spots for organizations today.

According to SecurityScorecard, 98% of organizations have a vendor that has suffered a breach in the last two years. That’s nearly universal exposure.

The lesson: even if you do everything right, you can still get burned through your ecosystem.

Recent examples prove the point:

• SolarWinds → hackers compromised a trusted vendor update, affecting thousands.

• MOVEit → a widely used file transfer tool was exploited, impacting 2,500+ firms.

• CrowdStrike update → a faulty security vendor patch triggered global Windows outages.

Best practices in TPRM include:

• Know your vendors. Keep an inventory, especially as shadow vendors are a hidden risk.

• Assess them. Use questionnaires, audits, and ratings.

• Monitor continuously. Risk changes with time and assessments can’t be one-off.

• Plan for incidents. Assume at least one vendor will get breached; how will you respond?

• Breach Simulations. Simulate how you would respond if a real supply chain incident happened.

This TPRM challenge is so significant that many organizations - including my own team at Krofturg.com - are working on tools that make vendor lifecycle and risk management more practical, from onboarding through offboarding.

What If You Had $100k to Build a Security Program?

Ok let's play a game: Imagine the CEO hands you a $100,000 check and says: “Make us safer.” Not the largest budget, but It’s a fantastic problem for this article, and also a good test of prioritization. Spend it on one shiny product and you’ll have an expensive toy. Distribute it wisely, and you’ll create real risk reduction that compounds over time.

Below is a theoretical way to spend this budget on your brand new security program:

• People & Services - $10K (10%)
• Deliver targeted staff awareness (phishing simulator + follow-up training).
• Fractional CISO / vCISO for 3–6 months (strategy + roadmapping).
• A few days of professional services: initial pen test, or MSSP onboarding, or a consultant to implement logging.
• Process & Training - $10K (10%)
• Risk Assessment
• Draft core policies (Acceptable Use, Risk Management Framework, Access management, Incident Response, Data Classification).
• Run one tabletop incident exercise and produce a 1-page IR playbook.
• Technology - $60K (65%)
• Priority controls: MFA rollout across critical accounts; email security; EDR/next-gen endpoint protection; basic logging/centralization and cloud-native monitoring; backups with tested restore.
• Prefer managed or cloud-native options to reduce ops overhead.
• Third-Party Risk Management - $15K (15%)
• Vendor assessment tooling or consultant engagement to run automated questionnaires and at least 3 deep reviews of highest-risk vendors.
• Set up basic vendor inventory and an initial continuous rating (or obtain 6–12 months of a ratings service trial).

A pragmatic timeline (0–12 months)

• 0–3 months - Stabilize: inventory critical assets, scope crown-jewel systems, identify key risk areas, deploy MFA on critical systems, email security, begin vendor inventory.
• 3–6 months - Harden: implement EDR, centralize key logs into a basic monitoring pipeline, complete IR tabletop, perform the initial pen test, and assess top 5 vendors.
• 6–12 months - Scale & Measure: tune alerts, expand logging, run follow-up remediation, onboard continuous vendor monitoring, and mature policies.

In Summary: Building Smart > Building Fast

Building a security program from scratch is never about chasing the latest tools or copying frameworks word for word. It’s about making smart, risk-based decisions step by step.

Here are the timeless lessons I keep coming back to:

• Start with the foundations: risk assessment, asset inventory, data classification, policies, and awareness.

• Deliver quick wins while building: MFA, monitoring, and email security provide immediate value no matter what the risk assessment shows.

• Budget wisely: balance people, process, and technology.

• Don’t forget third-party risk: your ecosystem is only as strong as its weakest vendor link.

• Think long-term: cybersecurity is a journey, not a one-time project. Programs evolve with the business.

The key takeaway: building smart, deliberate, and risk-aligned will always take you further than building fast.

If you’d like to dive deeper, you can:

👉 Watch my full talk on KSU MediaSpace

👉 Connect with me on LinkedIn or through Cyberkach; I’m happy to share templates, my $100K allocation model, or just swap lessons from the field. Good luck building!