Cybersecurity Regulations Change. Your Security Architecture Doesn't Have To.

If you're an MSP or MSSP, you've probably had some version of this conversation with a customer: “We just found out we need to comply with NIS2, DORA , HIPAA, PCI DSS... What do we need to buy?”

It's a fair question. It's also usually the wrong first question — and answering it well is where you create real value for your customers.

Because if you work in cybersecurity or IT, it can sometimes feel like there is a new cybersecurity law, regulation, framework, or compliance requirement around every corner.

NIS2. The Cyber Resilience Act. DORA. Industry-specific requirements. State and national regulations. And those are just some of the requirements your customers may need to understand, depending on where they operate and what they do.

Keeping up with all of them is difficult enough. Figuring out what they actually mean for the technology you manage on their behalf can be even harder.

But there's an important point that can get lost in the discussion:

Compliance requirements may be different, but many of the security practices needed to meet them are remarkably similar.

Different regulations, familiar security questions

A regulation might require an organization to demonstrate that it has appropriate access controls. Another might emphasize protecting networks and information systems. Another might require organizations to manage risk, detect and respond to incidents, or protect their supply chain.

Read individually, those sound like different requirements.

From an IT or cybersecurity perspective, however, they tend to lead to the same handful of questions:

• Are we controlling who can access our systems?
• Are we limiting what users and applications can communicate with?
• Are we protecting our network from known and emerging threats?
• Are we monitoring what is happening?
• Can we identify suspicious activity?
• Do we have controls in place to reduce the likelihood and impact of an incident?

These aren't new questions. Good cybersecurity teams — and good MSPs — have been asking them for years.

The changing regulatory landscape makes it more important to answer those questions and demonstrate that they're being answered to your customers.

This is where the overlap becomes useful

One of the mistakes organizations can make — and one I'd caution your customers against — is treating every regulation as an entirely separate security project.

That approach produces a long list of individual compliance initiatives, each with its own controls, documentation, and technology requirements. It's expensive, it's hard to maintain, and it doesn't scale.

Instead, it's more useful to look for the common security capabilities underneath those requirements.

Network security controls, for example, can contribute to multiple security objectives simultaneously. Intrusion prevention can help detect and block malicious activity. Application controls can restrict potentially risky applications. Web and DNS filtering can reduce exposure to malicious or inappropriate destinations. Antivirus and advanced malware protection can provide additional layers of defense.

The technology isn't “for NIS2” or “for regulation X.”

It's technology that implements security controls to help an organization satisfy requirements across multiple regulations and frameworks — which is exactly the kind of efficiency your customers are looking for from you.

The firewall can be part of that foundation

When discussing compliance and firewalls, it's tempting to focus on the security services available as subscriptions. Those services are valuable, but they're only part of the story.

A firewall's foundational networking capabilities can be just as important.

A Firebox, for example, can use security zones and VLANs to segment networks and control how systems communicate with one another. Rather than allowing every device on a network to communicate freely, you can help your customers create boundaries between users, servers, guest networks, IoT devices, management systems, and other resources.

That segmentation helps implement a fundamental security principle: not every system needs to be able to communicate with every other system.

Access control is another example. Firewall policies determine which traffic is permitted between networks and services, while built-in protections such as brute-force prevention help defend against attempts to gain unauthorized access.

None of that requires a customer to purchase a separate subscription for every security objective. These are fundamental security controls that can be built into the network's design from day one.

Then there are the additional security services that add further layers of protection. Depending on the Firebox model and licensing, capabilities such as Intrusion Prevention Service, Gateway AntiVirus, APT Blocker, Application Control, WebBlocker, DNSWatch, Botnet Detection, Geolocation, and Data Loss Prevention provide additional protection against specific threats and attack techniques.

The important distinction is that these capabilities work together. A secure network isn't created by one feature — it's created by layers of controls that work together to reduce risk.

That's also why I wouldn't approach a new regulation by asking, “Which security product do I need to become compliant?”

I'd start by asking, “What security controls does this requirement expect, what risks are those controls intended to address, and what capabilities do we already have?”

That change in perspective makes navigating new regulations considerably more manageable — and it's a conversation you're well-positioned to lead. Enabling a security service isn't the same as using it well. It's configuring it appropriately for the customer's specific risk profile and security requirements.

DNSWatch, for example, can help protect users from malicious domains, while WebBlocker provides more granular web-content filtering. Intrusion Prevention and Application Control provide additional inspection and control over network traffic and application behavior.

Those capabilities serve as building blocks for a broader security strategy — one you can tailor to each customer rather than reselling the same bundle to everyone.

Compliance isn't a checkbox

There's another distinction worth making clear to your customers: having a security feature enabled does not automatically make an organization compliant.

Compliance depends on the applicable regulation, the organization's circumstances, the way controls are implemented, and the evidence available to demonstrate that those controls are operating effectively.

A firewall configured with every security service enabled isn't necessarily more compliant than one configured deliberately around the organization's actual risks. In fact, the opposite can sometimes be true — noise and misconfiguration can undermine the very controls a regulation expects to see working.

Your customers need to understand why a control exists, what risk it addresses, how it's configured, and how its effectiveness is monitored. That's where you, as their MSP or MSSP, become particularly valuable.

Turning regulation into a service opportunity

For service providers, the growing regulatory landscape creates both a challenge and an opportunity.

Customers may come to you asking, “Can you make us compliant?”

The better conversation is usually:

“Let's understand what your requirements are, identify the risks and controls that apply to you, and determine how your existing security architecture can address them.”

That approach often reveals that a customer already has many of the necessary capabilities. They may need to configure them differently, close gaps, improve monitoring, document the controls, or establish better operational processes — all services you can package and bill for.

For you and your technical teams, this means the ability to translate regulations into practical technical controls is becoming increasingly valuable. You don't necessarily need to memorize every paragraph of every regulation. You do need to understand the security outcomes those requirements aim to achieve — and be able to map them to what's already in your customer's network.

The regulations will keep changing

I don't expect the regulatory landscape to get simpler anytime soon. New laws will appear. Existing regulations will be amended. Different jurisdictions will introduce different requirements. And your customers will keep asking what all of this means for them.

That can feel overwhelming.

But the best way to approach it isn't to start with the regulation. Start with the security fundamentals.

Protect access. Segment networks. Control applications. Prevent and detect threats. Protect users from malicious destinations. Monitor activity. Prepare for incidents. Manage risk. Document what you're doing and why.

Then map those capabilities to the requirements for each customer.

The specific regulations may change, but those fundamental security practices aren't going away. And when a platform like Firebox delivers multiple capabilities in a single system, it becomes a durable building block you can use to implement and maintain those controls across a changing compliance landscape — for every customer, across every new regulation that comes next.

The goal shouldn't be to build a different security architecture for every new regulation. The goal should be to build a strong security architecture that can adapt as the regulations change.