Building a Cybersecurity Capability from Scratch

The Starting Point: Understand Your Risk

Before building a security capability, you must understand what you are securing and what you are securing against. This sounds obvious, but it is the step most organisations skip. They buy tools because a vendor, a regulator, or a breach in the news told them to, not because they have assessed their own risk. The result is a security function that is well-equipped but poorly directed defending against generic threats while missing the threats that matter to their specific business.

A risk assessment answers three questions: What are our crown-jewel assets (the data, systems, and capabilities whose loss would cause the most damage)? What are the threats to those assets (who would attack, how, and why)? What are our current vulnerabilities (where are the gaps in our current defences)? The output is a prioritised risk register that directs every subsequent investment. Without it, security spending is guesswork.

Choose Your Framework

A security framework provides the structure for your capability. It defines the domains of security you must address and the outcomes you must achieve in each. The most widely adopted frameworks are the NIST Cybersecurity Framework (CSF) and ISO/IEC 27001. You do not need to adopt a framework formally to benefit from it you need it as a blueprint to ensure you are not missing critical domains.

The NIST CSF organises security into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. This structure is useful because it maps to the lifecycle of security: you govern the program, identify what you are protecting, protect it, detect when protection fails, respond to the detection, and recover from the incident. Each function has categories and subcategories that define specific outcomes. Use the framework as a checklist for completeness, not as a compliance exercise.

The NIST CSF functions explained

• Govern: The policies, roles, and risk management processes that direct the security program. Without governance, security is a collection of technical controls with no strategic direction.
• Identify: Asset management, risk assessment, and supply chain risk. You cannot protect what you have not identified, and you cannot prioritise without understanding risk.
• Protect: Access control, data security, training, and protective technology. This is the preventive layer the controls that reduce the likelihood of a successful attack.
• Detect: Continuous monitoring and threat detection. The layer that tells you when protection has failed and an incident is in progress.
• Respond: Incident response planning and execution. The layer that contains the incident, eradicates the threat, and restores operations.
• Recover: Recovery planning, improvements, and communication. The layer that restores the business to normal and incorporates lessons learned.

Design the Operating Model

The operating model defines how the security function works: its structure, its processes, and its relationship to the rest of the business. The most common mistake is building a security function that operates in isolation, disconnected from the business it is protecting. Security that is not integrated with the business becomes a bottleneck, not a protector.

The operating model must answer: Who owns security risk? (Answer: the business, not the security team. Security advises and enables; the business owns the risk.) How does security engage with development and operations? (Answer: embedded, not bolted on. Security must be part of the development pipeline, not a gate at the end.) How is security performance measured? (Answer: by risk reduction, not by activity. Alerts generated, vulnerabilities patched, and incidents responded to are inputs; risk reduced is the output.)

The goal of a security function is not to generate alerts. It is to reduce risk. If your security program cannot demonstrate risk reduction, it is not working no matter how many tools it has.

Codesigns Cybersecurity Practice

Build the Team: The Security Talent Stack

The talent stack is where most security programs stall. The roles required are scarce, the compensation is high, and the competition is intense. Building a security team from scratch requires a clear understanding of which roles you need, which you can hire, which you must build, and which you should partner for.

The core roles

• CISO or security leader: Sets strategy, owns the relationship with the business, and secures budget. This is the most important hire. A strong CISO builds the function; a weak one collects tools.
• Security architect: Designs the security architecture, selects controls, and ensures they work as a system. This role requires deep technical expertise and business understanding.
• Security engineers: Implement and operate security controls: firewalls, endpoint protection, IAM, SIEM. These are the hands-on practitioners who make the architecture real.
• SOC analysts: Monitor for threats, triage alerts, and respond to incidents. The SOC is the operational heart of the security function.
• GRC specialist: Manages governance, risk, and compliance: policies, risk assessments, audit support, and regulatory alignment. Often undervalued but essential for a sustainable program.

The build-vs-buy-vs-partner decision

Not every role needs to be a full-time hire, and not every capability needs to be built internally. The decision for each role depends on the strategic importance, the frequency of need, and the availability of talent. A CISO is a strategic hire: full-time, internal, and critical. A SOC analyst is an operational hire: can be internal or managed (MSSP). A penetration tester is a specialised need: often better outsourced to a partner who does it at scale. The right mix is rarely all-internal or all-outsourced it is a deliberate combination based on the organisation's needs.

Implement the Controls: Priority Over Coverage

When building from scratch, the temptation is to implement every control at once. This is a mistake. It produces a shallow implementation of everything rather than a deep implementation of what matters. The priority-driven approach implements the controls that reduce the most risk first, then expands outward.

1. 01Priority 1 - Identity and access: MFA, privileged access management, and identity lifecycle. This is the highest-ROI security investment because stolen credentials are the number one attack vector.
2. 02Priority 2 - Endpoint protection: Modern endpoint detection and response (EDR) on every endpoint. Endpoints are the most common entry point and the most common lateral movement platform.
3. 03Priority 3 - Data protection: Discover and classify data, encrypt at rest and in transit, and implement data loss prevention. You cannot protect data you have not found.
4. 04Priority 4 - Network security: Microsegmentation, secure connectivity, and egress filtering. The network is the lateral movement path; segmenting it limits blast radius.
5. 05Priority 5 - Security monitoring: SIEM or security data lake, threat detection use cases, and a SOC to monitor and respond. This is the detect-and-respond capability that catches what prevention misses.
6. 06Priority 6 - Vulnerability management: Asset inventory, vulnerability scanning, and prioritised remediation. You cannot patch what you have not found, and you cannot patch everything at once.

Measure What Matters

A security function that cannot measure its performance cannot improve it, and cannot demonstrate its value to the business. The metrics that matter are not activity metrics (alerts generated, vulnerabilities scanned) but outcome metrics: risk reduction, incident impact, and time-to-respond. The security function should report to the business in terms of risk, not in terms of activity.

• Risk reduction: Track the organisation's risk score over time, using the risk register as the baseline. The goal is a downward trend.
• Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR): The speed metrics that determine incident impact.
• Incident impact: The number, severity, and cost of security incidents. The goal is fewer, smaller, cheaper incidents.
• Coverage: The percentage of assets, identities, and data covered by the deployed controls. The goal is increasing coverage of critical assets.
• Control effectiveness: The percentage of simulated attacks that are detected and blocked. This tests whether controls work, not just whether they exist.

The Maturity Journey

A security capability is not built in a quarter. It is a multi-year journey through maturity stages, and understanding the stages prevents the frustration of expecting too much too soon.

Stage 1: Foundational (0-12 months)

The first year is about establishing the basics: risk assessment, framework selection, core controls (identity, endpoint, data), and a basic monitoring capability. The goal is not perfection it is coverage of the highest-risk assets and the establishment of the security function as a recognised part of the business.

Stage 2: Operational (12-24 months)

The second year is about operationalising the controls: a functioning SOC, tested incident response, vulnerability management at scale, and the metrics that demonstrate performance. The goal is a security function that can detect, respond, and recover not just protect.

Stage 3: Mature (24-36 months)

The third year is about maturity: threat intelligence, proactive hunting, automated response, and integration with the business. The goal is a security function that is a strategic enabler, not just a technical control. At this stage, security is a capability that the business trusts and relies on.

Conclusion

Building a cybersecurity capability from scratch is not a procurement exercise. It is an organisational design exercise that requires a framework, an operating model, a team, and a measurement system. The organisations that succeed are not the ones that buy the most tools they are the ones that build the function that makes the tools effective.

The question is not whether your organisation needs a cybersecurity capability. Every organisation does. The question is whether you will build it deliberately, with a framework and the right talent, or reactively, after a breach forces the issue. At Codesigns, we help you build it deliberately because the cost of building it before the breach is a fraction of the cost of building it after.