Many organizations have invested heavily in security operations.

They have a SOC. They have an MSSP. They monitor alerts around the clock. They identify vulnerabilities. They respond to incidents.

And yet leadership may still have an uncomfortable question:

Do we actually have a complete security program?

The answer depends on what exists beyond monitoring.

A Managed Security Service Provider (MSSP) can provide a critical operational foundation through continuous monitoring, threat detection, incident response, and security operations. AWS, for example, describes MSSP services as providing continuous threat detection and incident response through 24/7 security monitoring.

But monitoring is only one part of a mature cybersecurity program.

• Who determines what the security architecture should look like?

• Who translates that architecture into working technical controls?

• Who fixes vulnerabilities after they're identified?

• Who reconnects integrations when the technology stack changes?

• Who ensures technical decisions satisfy regulatory and contractual requirements?

• And who makes sure all of those functions work together?

At Steel Patriot Partners, we think about a mature security program across four interconnected pillars:

1. Managed Security Services (MSSP)
2. Security Architecture
3. Security Engineering
4. Compliance

Each serves a different purpose.

• The MSSP sees and responds.

• Security Architecture designs and directs.

• Security Engineering builds, fixes, and maintains.

• Compliance defines and validates applicable requirements and evidence.

Remove one, and gaps can appear between strategy, visibility, execution, and assurance.

The goal isn't simply to have all four boxes checked.

The goal is to make them operate as one security program.

Key Takeaways

• An MSSP is foundational, but security monitoring alone does not constitute a complete security program.
• Security Architecture establishes the target state and determines how security technologies and capabilities should work together.
• Security Engineering converts strategy and findings into implementation, configuration, automation, remediation, and hardening.
• Compliance translates applicable regulatory, contractual, and framework requirements into policies, controls, evidence, monitoring, and reporting.
• Detection without remediation can leave known weaknesses unresolved.
• Engineering without architecture risks becoming tactical and reactive.
• Architecture without operational intelligence can become disconnected from the actual threat environment.
• Compliance works best as an outcome of a well-designed and well-operated security program, not as a separate security silo.
• Organizations should assess each pillar independently and then examine how information and accountability move between them.

Security Programs Need More Than Monitoring

One of the questions we increasingly hear from organizations is deceptively simple:

What does "good" actually look like?

An organization may have outsourced security monitoring and incident response. Leadership knows that capability is important and may be comfortable with the provider.

But there can still be significant gaps elsewhere.

"The MSSP stuff is foundational, but very reactive. It's kind of table stakes where you have to have that at a minimum."

The distinction matters.

An MSSP can monitor an environment and identify suspicious activity, vulnerabilities, or other conditions requiring attention.

But who determines what the environment should look like? Who implements the changes Who makes sure those changes continue working? Who connects those activities to the organization's regulatory and contractual obligations?

Those questions lead us to four different, but interdependent, security capabilities.

The Four Pillars of a Security Program

The model below illustrates how those capabilities can sit underneath a Security Program Leader.

• Pillar 1 — MSSP: 24/7 monitoring, SOC operations, threat detection, containment, threat hunting, and reporting.

• Pillar 2 — Security Architecture: Target-state architecture, cloud and on-premises security design, zero trust strategy, architecture reviews, and technical guidance.

• Pillar 3 — Security Engineering: Security implementation, automation and orchestration, identity and access management, vulnerability remediation, and hardening.

• Pillar 4 — Compliance: Regulatory and framework alignment, policies and controls, audit support, evidence management, continuous monitoring, and compliance reporting.

This isn't intended to suggest that every organization must staff four separate departments.

The functions can be internal, outsourced, co-sourced, or divided among multiple teams.

What matters is that the capabilities and ownership exist.

That distinction is important because an organization can have a strong capability in one pillar and significant gaps in another.

Pillar 1: MSSP — See What's Happening

The first pillar is security operations.

For many organizations, this is provided through an MSSP or a combination of an internal SOC and external managed security services.

Its responsibilities may include:

• 24/7 security monitoring
• SOC operations
• Threat detection
• Incident response and containment
• Threat hunting
• Vulnerability identification
• Security reporting
• Escalation of issues requiring remediation

AWS describes MSSPs as delivering continuous monitoring, threat detection, and incident response, with its MSSP competency spanning areas including infrastructure security, workload security, application security, identity and access management, incident response, and cyber recovery.

This capability is essential, but there is an important limitation.

Seeing the problem isn't necessarily the same as fixing the problem.

Detection Without Execution Creates a Dangerous Gap

Imagine your MSSP identifies a recurring vulnerability.

The alert is legitimate. The vulnerability has been investigated. The organization knows where the issue exists.

Now what?

• Someone has to change the environment.

• A configuration may need to be modified.

• An IAM policy may need to change.

• A vulnerability may need to be remediated.

• A system may need to be hardened.

• An API or integration may need to be repaired.

• Automation may need to be implemented.

• The architecture itself may need to change.

That isn't always the MSSP's job.

"MSSP will also identify where the issues exist, maybe where the vulnerabilities are coming from and indicate what needs to be done or what needs to be addressed from a gap perspective. But the MSSP is not actually implementing those changes."

The exact boundary will vary by provider, some MSSPs offer broader remediation and engineering services, but the organizational question remains:

Who owns the fix?

This challenge is well recognized across the industry. An ISC2 practitioner article on vulnerability management describes finding vulnerabilities as comparatively easy and remediation as the more difficult organizational challenge, warning that visibility without action creates liability rather than reducing it.

That is where Security Engineering becomes critical.

But before engineers can implement the target state, someone needs to define it.

Pillar 2: Security Architecture — Decide What the Program Should Become

Security Architecture is the strategic design layer.

Its job isn't simply to decide whether the company should purchase Tool A or Tool B.

That's part of it.

But mature security architecture asks broader questions:

• What should our target-state security architecture look like?

• How should cloud, on-premises, identity, network, application, and data-security capabilities interact?

• Where should security controls live?

• What should be standardized?

• What should be automated?

• How should Zero Trust principles influence the design?

• What architecture will support the business three years from now—not simply solve today's ticket?

NIST's NICE workforce guidance describes systems security architecture as translating technology and environmental conditions—including law and regulation—into system and security designs and processes.

That is fundamentally different from reacting to an individual alert.

Architecture provides the strategic direction of travel.

Tactical Technology Decisions Are Not the Same as Security Architecture

Organizations sometimes assume they have security architecture because someone is making decisions about security technology.

There may be a senior engineer deciding:

• Should we keep this firewall?

• Should we replace this identity platform?

• How should this tool be configured?

Those decisions matter.

But individually, they don't necessarily constitute a security architecture program.

"You have one person that is maybe making some recommendations and decisions relative to what tools you put in place and configure and remove. But that's just a very small piece that's more tactical, decision-focused. It's not strategic in terms of what should the architecture look like overall."

A mature architecture function creates a reference point against which individual decisions can be evaluated.

Instead of asking:

"Is this a good security tool?"

It asks:

"Does this technology belong in the security architecture we're trying to build?"

That's a much more useful question.

Architecture Must Connect to the Business

Security Architecture also cannot exist independently of business strategy.

NIST's Cybersecurity Framework 2.0 reinforces this broader view of cybersecurity governance. NIST says the framework can help organizations align and prioritize cybersecurity activities with business and mission requirements, risk tolerances, and resources.

That's important because a technically elegant security architecture that prevents the business from operating effectively isn't a successful architecture.

• Security leaders have to consider:

• Business objectives.

• Risk tolerance.

• Customer requirements.

• Cloud strategy.

• M&A.

• Workforce.

• Regulation.

• Cost.

• Technical debt.

• Resilience.

• Growth.

Security Architecture turns those inputs into a target state.

Then someone has to build it.

Pillar 3: Security Engineering — Make the Strategy Real

If Security Architecture determines what the security program should look like, Security Engineering determines how to make it work.

This is the execution layer.

"Security engineering is kind of the glue between the security architecture and the strategy of the program and what the MSSP discovers in terms of gaps or issues within your program."

That "glue" is critical.

NIST's Systems Security Engineering guidance similarly describes security engineering as applying systems-security expertise to develop systems that satisfy an organizational mission or business requirements while accounting for stakeholder protection needs and security requirements. NIST specifically identifies responsibilities involving architecture, threat and vulnerability data, engineering trade-offs, security technologies, and risk decisions.

In practical terms, Security Engineering may include:

• Building and implementing security solutions
• Configuring security technologies
• Identity and access management
• Vulnerability remediation
• System hardening
• Automation and orchestration
• API and integration maintenance
• Infrastructure changes
• Security-control implementation
• Technical remediation
• Maintaining controls as environments change

Architecture says:

Here's where we're going.

Engineering says:

Here's how we're going to get there.

Security Engineering Closes the Loop

The relationship between the MSSP and Security Engineering is particularly important.

Consider the lifecycle:

The MSSP detects a condition.

↓

The issue is analyzed and prioritized.

↓

Security Engineering determines the technical remediation.

↓

Engineering implements the fix.

↓

Monitoring validates whether the condition has been resolved or reappears.

↓

Architecture evaluates whether the incident reveals a broader design issue.

That feedback loop turns individual alerts into program improvement.

Without it, organizations can become trapped in a cycle of:

Detect → Ticket → Close → Detect Again

rather than:

Detect → Understand → Remediate → Validate → Improve

The distinction is enormous.

Google's description of its own vulnerability-management approach makes a similar point: vulnerabilities are inevitable, so organizations need mechanisms not merely for finding them, but for tracking and fixing them.

Architecture and Engineering Aren't Interchangeable

Security Architecture and Security Engineering frequently get combined in organizational charts.

They are closely related, but they answer different questions.

Security Architecture asks:

• What should we build?

• Why should we build it?

• How should the pieces interact?

• What should the target state look like?

• How does it support business and risk objectives?

Security Engineering asks:

• How do we implement it?

• How do we configure it?

• How do we automate it?

• How do we remediate what isn't working?

• How do we keep it working as the environment changes?

A strong engineer without architectural direction may become consumed by tactical work.

A strong architect without engineering capacity may produce excellent designs that never become operational.

Strategy without execution doesn't reduce risk.

Execution without strategy can create expensive technical debt.

Organizations need both.

Pillar 4: Compliance — Define and Validate the Required Outcomes

Then there is Compliance.

Compliance tends to be narrower than the overall cybersecurity program because it is driven by defined requirements.

• FedRAMP.

• CMMC.

• NIST SP 800-171.

• HIPAA.

• HITRUST.

• SOC 2.

• ISO 27001.

• CJIS.

• PCI DSS.

• Contractual obligations.

• Customer security requirements.

Each establishes particular expectations that an organization may need to demonstrate.

Compliance activities may include:

• Framework and regulatory alignment
• Policy development
• Control development
• Evidence collection and management
• Audit preparation and support
• Continuous monitoring
• Compliance reporting
• Control testing
• Documentation
• Gap analysis and remediation tracking

NIST CSF 2.0 explicitly recognizes this relationship. Its Govern function includes an outcome requiring that legal, regulatory, and contractual cybersecurity requirements be understood and managed.

But there is a crucial point:

Compliance should not define the boundaries of the security program.

Compliance Is a Sliver of the Environment—Security Has to Protect the Whole Business

A particular framework may apply to a defined system boundary, regulated workload, category of data, government cloud environment, business unit, or particular contract. But attackers don't necessarily respect those boundaries.

Your overall security architecture has to account for the broader enterprise.

Compliance can be described as a "sliver" of the broader security environment:

"You are designing the architecture for the entire program, inclusive of the areas that may be subject to compliance and the areas that are not subject to compliance."

This is one of the most important distinctions for security leaders.

A compliance-driven security program asks:

What do we have to do to satisfy the framework?

A risk-driven security program asks:

What do we need to do to protect the business—and how do we design those capabilities so they also satisfy applicable compliance requirements?

That leads to a different operating philosophy.

Make Compliance an Outcome of Good Security Architecture

"You need to strategically ensure you're architecting it in such a way so that compliance becomes an outcome of that architecture."

That doesn't mean compliance happens automatically.

Organizations still need control mapping, evidence, policies, documentation, testing, assessment support, and framework-specific processes.

But the underlying technical capabilities shouldn't be created solely for the audit.

1. Identity architecture should protect the organization and satisfy applicable IAM controls.

2. Logging should help detect threats and produce required audit evidence.

3. Vulnerability management should reduce exploitable exposure and satisfy remediation requirements.

4. Configuration management should improve operational resilience and demonstrate control effectiveness.

5. Incident response should help contain actual incidents and meet regulatory or contractual requirements.

That's how organizations begin moving from compliance-driven security toward security-driven compliance.

The Four Pillars Reinforce Each Other

The most important feature of this model isn't any individual pillar.

It's the relationship among them.

NIST CSF 2.0 offers a useful parallel. NIST organizes cybersecurity outcomes around six concurrent functions—Govern, Identify, Protect, Detect, Respond, and Recover—and explicitly states that together they provide a comprehensive view for managing cybersecurity risk.

SPP's four-pillar model isn't a replacement for the CSF. It is an operating model for thinking about who provides the strategic, operational, technical, and compliance capabilities needed to produce those kinds of outcomes.

Consider how the pillars interact:

Security Architecture → MSSP

Architecture determines what systems, controls, telemetry, integrations, and security capabilities should exist. The MSSP monitors the resulting environment.

MSSP → Security Engineering

Security operations identify threats, vulnerabilities, anomalies, and gaps. Engineering receives actionable findings and implements remediation.

Security Engineering → Architecture

Engineers discover technical constraints, dependencies, implementation challenges, and opportunities that should influence future architectural decisions.

Architecture → Compliance

Architecture should incorporate applicable regulatory, contractual, and framework requirements into the target state.

Compliance → Engineering

Compliance establishes control requirements and remediation needs that engineers may need to implement technically.

Engineering → MSSP

Engineering changes systems, controls, configurations, integrations, and APIs. Monitoring must evolve alongside those changes.

MSSP → Compliance

Security operations generate logs, alerts, incident records, vulnerability information, and other evidence that can support continuous monitoring and assessments.

The program becomes a cycle rather than four independent departments.

Where Security Programs Commonly Break Down

Looking at cybersecurity through these four pillars can help leadership identify gaps that aren't immediately obvious.

An organization might have an excellent MSSP but no engineering resources capable of remediating what it finds.

Another may have talented engineers but no formal target-state architecture guiding their work.

Another may have a sophisticated compliance organization that generates remediation requirements faster than the engineering organization can implement them.

Another may have strong architecture and engineering capabilities but insufficient 24/7 visibility into the operating environment.

And another may have all four functions, but they rarely communicate.

That last scenario can be particularly dangerous.

Because the boxes exist, the organization looks mature on paper, but the operating model is fragmented.

The Security Leader's Job Is to Connect the Pillars

This is why the Security Program Leader sits above the four pillars in our model.

The leader's job isn't to personally perform every function. It's to ensure the functions operate as a system.

That means asking questions like:

MSSP
Are we monitoring the right environment, and are actionable findings reaching the people who can fix them?

Security Architecture
Do we have a documented target state, or are we making technology decisions one at a time?

Security Engineering
Do we have sufficient capacity and expertise to implement and maintain the controls we're designing?

Compliance
Are regulatory and contractual requirements integrated into the program, or are we running a parallel "audit program" disconnected from security operations?

And then the most important question:

What happens between the pillars?

Assess Capability, Not Just Headcount

An organization does not necessarily need four large internal teams.

A midmarket organization may have:

• An outsourced MSSP
• A fractional or advisory security architect
• Co-sourced security engineers
• An internal compliance leader supported by an implementation partner

A larger enterprise may operate all four functions internally.

Another organization may use a hybrid model.

The appropriate structure depends on size, risk, regulatory requirements, architecture, existing talent, and budget.

The important thing is to distinguish capability from organizational structure.

Don't ask only:

"Do we have a security architect?"

Ask:

"Do we have the security architecture capability the business requires?"

Don't ask only:

"Do we have engineers?"

Ask:

"Can we reliably implement and remediate the security changes our environment requires?"

Don't ask only:

"Do we have an MSSP?"

Ask:

"Are we detecting, escalating, responding to, and learning from security conditions effectively?"

Don't ask only:

"Are we compliant?"

Ask:

"Are our applicable requirements built into the way the security program operates?"

Those questions reveal maturity much more effectively than an org chart.

A Practical Four-Pillar Security Program Assessment

Leadership can begin by evaluating each pillar against three questions:

Then ask a fourth question across all of them:

How does information move from one pillar to the next?

That's often where the real gaps emerge.

The Executive Perspective: Don't Confuse Visibility With Security

Cybersecurity has become very good at generating information.

• Alerts.

• Dashboards.

• Vulnerabilities.

• Risk scores.

• Audit findings.

• Threat intelligence.

• Compliance gaps.

But information only reduces risk when the organization can convert it into action.

That is why a mature program requires more than visibility.

It needs:

1. Direction.

2. Detection.

3. Execution.

4. Validation.

The financial stakes reinforce why that matters. IBM's 2025 Cost of a Data Breach research put the global average cost of a breach at $4.44 million, while the average in the United States reached a record $10.22 million. The same study found that faster identification and containment helped reduce the global average year over year.

The takeaway isn't that every organization needs a bigger security department.

It's that the security operating model needs to be able to move from:

Strategy → Detection → Decision → Remediation → Validation → Improvement

without breaking down between teams.

Steel Patriot Partners' Recommendations

For organizations evaluating the maturity of their security programs, we recommend starting with the operating model rather than immediately buying another technology.

Map the four capabilities. Determine what exists today across MSSP/Security Operations, Security Architecture, Security Engineering, and Compliance.

Assess maturity independently. One strong pillar can hide significant weakness elsewhere.

Document ownership. Every alert, architectural decision, remediation requirement, and compliance gap needs an accountable owner.

Trace the handoffs. Determine how an MSSP finding becomes an engineering action—and how completion is validated.

Build a target-state architecture. Stop allowing individual technology decisions to become the architecture by default.

Connect compliance to architecture and engineering. Requirements should influence the security program before an assessor identifies a gap.

Measure remediation, not simply detection. Finding more vulnerabilities isn't success if the organization cannot prioritize and eliminate meaningful exposure.

Choose the right sourcing model for each pillar. Internal, outsourced, and co-sourced models can all work. The objective is complete capability, clear accountability, and effective integration.

Final Thoughts

An MSSP can tell you something is wrong.

A Security Architect can help determine what the environment should look like instead.

A Security Engineer can make the technical changes required to get there.

Compliance can ensure the resulting program satisfies the obligations that matter to the business.

None of those capabilities should operate independently because a mature security program isn't a collection of products, vendors, teams, or certifications.

It's an operating system for managing cyber risk.

The organizations that get this right won't simply become better at finding vulnerabilities.

They'll become better at turning security intelligence into action, and turning that action into a stronger, more resilient, and more defensible business.

FAQ

What are the four pillars of a mature security program?

In Steel Patriot Partners' operating model, the four pillars are MSSP/Security Operations, Security Architecture, Security Engineering, and Compliance. They represent complementary capabilities for monitoring the environment, defining the target state, implementing and maintaining security controls, and managing applicable requirements.

What's the difference between an MSSP and Security Engineering?

An MSSP typically focuses on operational capabilities such as monitoring, threat detection, investigation, incident response, and reporting. Security Engineering focuses more heavily on implementing, configuring, automating, hardening, integrating, and remediating the technical environment. Exact service boundaries vary by provider.

What's the difference between Security Architecture and Security Engineering?

Security Architecture establishes the strategic and technical target state—what should be built and how security capabilities should interact. Security Engineering translates that design into working technology and maintains it as the environment changes.

Can an MSSP remediate vulnerabilities?

Some can and do. MSSP offerings vary significantly. The important organizational question is not whether remediation can be part of an MSSP contract, but whether there is explicit ownership, sufficient technical capability, and a reliable workflow for turning findings into verified remediation.

How does compliance fit into cybersecurity?

Compliance establishes particular regulatory, contractual, or framework-driven outcomes an organization must satisfy and demonstrate. A broader cybersecurity program should protect the enterprise beyond the boundaries of any single framework while incorporating applicable compliance requirements into architecture and operations.

Should compliance drive Security Architecture?

Compliance should be an important input, but not the only input. Architecture also needs to account for enterprise risk, business objectives, threats, resilience, technology strategy, cost, customers, and parts of the environment that may sit outside a particular compliance boundary.

Does every company need four separate security teams?

No. The model describes capabilities, not mandatory departments. Organizations can provide them internally, externally, or through a co-sourced model depending on their size, risk, resources, and requirements.

How should an organization identify gaps in its security program?

Start by mapping existing capabilities against the four pillars, assessing their maturity, identifying accountable owners, and tracing how information moves between them. Pay particular attention to handoffs. for example, what happens after the MSSP identifies a vulnerability or compliance identifies a control gap.

Need help navigating the changing IT landscape?

Whether you're evaluating IT strategy or modernizing your compliance program, Steel Patriot Partners helps organizations design, implement, and operate security programs that meet today's requirements while preparing for tomorrow's standards.

Schedule a consultation with our compliance experts to discuss your roadmap.