How to Move Firewall Management to an MSSP Without Losing Change Control or the Audit Trail

To move firewall management to an MSSP without losing change control, keep three things in-house: the approval of every rule change, a live copy of the firewall change logs, and the right to audit and leave. The provider operates the firewalls. You keep the decisions and the evidence. NIS2 and DORA both keep the obligation with you after you outsource, so the contract and the log flow have to be designed for that before the first ticket moves.

This guide is for the person who signs off the outsourcing and then faces the next audit: the network or security lead, the CISO, or the IT manager of a NIS2 entity. It covers what the rules say, what goes into the contract, how the change process is split, and how the handover runs without a gap in the audit trail. The general change process itself is covered in our firewall change management guide.

Does outsourcing move the compliance duty to the MSSP?

No. Outsourcing firewall operations moves the work, not the obligation. NIS2 says so in recital 83 of Directive (EU) 2022/2555: the risk-management and reporting obligations "should apply to the relevant essential and important entities regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof". Article 20(1) adds that management bodies approve the measures, oversee them and "can be held liable for infringements".

DORA is even more direct. Article 28(1)(a) of Regulation (EU) 2022/2554 states that financial entities using ICT services "shall, at all times, remain fully responsible" for compliance. In Germany, § 38 BSIG obliges the management of important and particularly important entities to implement and monitor the risk measures, and makes them liable to the entity for damage they culpably cause by breaching it.

The practical consequence: when the auditor asks who approved a rule that opened a path to a critical system, "our MSSP did it" is not an answer. You need the approval, the ticket and the log entry, and you need them without asking the provider for a favour.

What do NIS2 and DORA say about service providers?

Both frameworks treat the provider relationship as part of your own security. NIS2 Article 21(2)(d) lists "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" as a mandatory measure. Recital 85 names managed security service providers explicitly and encourages entities to put cybersecurity measures into "contractual arrangements with their direct suppliers and service providers". The German transposition carries the same point in § 30(2) No. 4 BSIG, and § 30(1) adds that compliance must be documented by the entity.

DORA turns this into contract content. Article 30(2)(d) requires provisions on access to, recovery and return of data "in an easily accessible format" when the contract ends. For critical or important functions, Article 30(3)(e) requires "unrestricted rights of access, inspection and audit", and Article 28(8) requires exit strategies, with exit plans that are "comprehensive, documented" and "sufficiently tested". Our DORA firewall compliance guide covers the rest of the regulation for banks and insurers.

Outside regulated finance, the BSI's IT-Grundschutz module OPS.2.3 Nutzung von Outsourcing gives the same direction: outsourcing contracts must include "ein Recht auf Prüfung, Revision und Audit" (A4), and the customer should keep enough skills and resources to avoid dependence on the provider (A8).

Which contract clauses keep change control with you?

The clauses that matter are the ones that decide who approves, who holds the records, and how you get out. Standard MSSP contracts are written around service levels and response times. In our experience they say little about change approval and less about who owns the change history. The table lists what we would put in before signing.

Clause	What it says	Source that backs it
Approval authority	No rule change goes live without approval by a named role on the customer side, except defined emergency changes	NIS2 Art. 20(1), management approves and oversees
Log copy to the customer	All configuration and audit logs are forwarded in real time to a customer-owned log store	BSIG § 30(1), compliance must be documented
Audit right	Customer, its auditor and the authority may inspect and audit the service	BSI OPS.2.3.A4; DORA Art. 30(3)(e)
Access scope	Which areas and services in your network the provider may access	BSI OPS.2.3.A14
Data return on exit	Rule base, objects, change history and tickets handed back in a readable, documented format	DORA Art. 30(2)(d); BSI OPS.2.3.A7
Exit and transition period	The provider keeps operating during a fixed transition period while you move to another provider or back in-house	DORA Art. 28(8) and 30(3)(f)
Subcontracting	Further outsourcing only with customer consent	BSI OPS.2.3.A4

The second row is the one we would fight hardest for. If the only copy of the change history sits in the provider's ticket system and management platform, your audit trail ends the day the contract does.

How do you split the change process with an MSSP?

Split it by decision, not by device. The provider can run every technical step of a firewall change. The customer has to own the steps where risk is accepted. A workable split looks like this:

• Request: raised by the customer's application or business owner, with purpose, source, destination, service and an end date for temporary access.
• Technical review: done by the MSSP. Shadowed rules, overly broad objects and conflicts with the zone model are flagged here.
• Risk approval: customer side, by a named role. For changes that touch critical zones, a second approver.
• Implementation and verification: MSSP, in an agreed window, with a rollback step written into the change.
• Closure and evidence: the change ID, the approval and the matching configuration log entry end up in your records, not only in theirs.

Emergency changes need their own path. Agree in advance which situations allow the provider to act first, and require a retrospective approval within a fixed time. Our post on firewall emergency change management describes that path in detail.

Who reviews the rule base after go-live?

You do, at least for recertification. The MSSP can prepare the review: unused rules, rules without owners, expired temporary access. The decision to keep or remove a rule belongs to the business owner on your side. The method is the one in our firewall rule recertification guide; outsourcing changes who prepares the list, not who signs it.

How do you keep your own copy of the audit trail?

Forward the configuration and audit logs from the firewalls and management platforms to a log store you own, from day one. Palo Alto Networks, Check Point and Fortinet all support this. Palo Alto Networks config logs record the administrator, the client, the command, the configuration path and "the values before and after the change", and Panorama can forward logs to external syslog, email or HTTP destinations. Check Point's Log Exporter supports "Export of Security logs, Audit logs, or both" over syslog with TLS. Fortinet's FortiManager keeps a configuration revision repository that you can download and compare.

Three details decide whether that copy is worth anything in an audit:

• Named accounts. Each MSSP engineer logs in with a personal account. A shared "mssp-admin" account turns every log entry into "someone at the provider".
• Change IDs in the commit comment. The provider writes your change ticket number into the commit or revision comment, so a log entry can be matched to an approval.
• Regular reconciliation. Compare the configuration log with the approved changes every month. Anything in the log without an approval is a finding. Our post on policy drift detection shows how to automate that comparison.

How does the handover itself run?

Run the handover as a firewall change project with its own evidence, in four steps. In our experience, most audit gaps in MSSP transitions come from the weeks around the handover, not from the steady state afterwards.

1. Baseline before the switch. Export the full rule base, objects and the change history from the outgoing team or provider. Record the configuration hash or revision number. This is the reference point for everything that follows.
2. Clean up first, then hand over. Remove rules without owners and expired temporary access before the provider takes over, or put them on a dated cleanup list in the contract. Otherwise the provider inherits your technical debt and bills you for maintaining it.
3. Parallel run. For the first weeks, the provider implements changes while your team approves and reviews each one against the log copy. This proves the process works before you depend on it.
4. Revoke old access. Remove the access of the outgoing team or provider, and document it. BSI OPS.2.3.A7 recommends checking that the provider's access rights were revoked when an outsourcing relationship ends.

The same four steps run in reverse when you leave the provider. That is why the exit clause and the log copy matter on day one: they make the next transition possible.

Which mistakes break the audit trail?

The mistakes that break the trail are organisational. These come up in almost every transition we have seen:

• The provider's ticket system as the only record. Your auditor gets screenshots on request, and only for as long as the contract runs.
• Approval by e-mail. "Go ahead" in a mail thread is hard to find, impossible to report on, and easy to dispute. The same problem applies to spreadsheet tracking.
• Multi-vendor estates split across providers. One MSSP for the perimeter, another for the data centre, a third for the cloud. Each keeps its own history. Without one view on your side, nobody can answer which change opened a path. Our multi-vendor firewall management guide covers that problem.
• No reporting in the contract. Agree a monthly change report from the provider: changes made, approvals, emergency changes, rule-base size. Our change management report template lists the fields.

When does an MSSP make sense for firewalls?

In our view, an MSSP makes sense when you lack people for round-the-clock operations, not when you want to hand over responsibility. Monitoring, routine changes, upgrades and vendor patching are good candidates to outsource. Rule approval, zone design and the decision which flows a business needs stay with you. Organisations that try to outsource those decisions usually find out at their next audit that they cannot.

Next step

Before you sign, test the contract against one question. Could you show an auditor the approval, the change and the log entry for any rule, without asking the provider? The free NIS2 Readiness Check walks through the records a firewall change process has to produce, whether your own team or a provider runs the firewalls.