A.8.21 Security of network services: what auditors test

What A.8.21 Security of network services asks an organization to prove

A.8.21 asks an organization to identify the security mechanisms, service levels and service requirements of its network services, to implement them, and to monitor that they keep working. The control applies whether the network service is run in house, such as a gateway your team administers, or supplied by an external provider, such as a carrier link, a managed firewall or a cloud networking service. For a compliance lead or engineer, the practical question is simple: can you show what each network service is supposed to do for security, what it was agreed to deliver, and how you know it is still doing that? Without those answers, network services become an unknown attack surface, and the gap between what a provider promises and what is actually delivered goes unnoticed until an incident exposes it.

The requirement is hard to satisfy for two reasons. First, it is split across ownership boundaries. Your own firewalls, VPN concentrators and DNS resolvers sit in your change process, while provider-run services are governed by contracts, service descriptions and support terms that may say little about security. Second, the evidence is scattered. The contract holds the agreed service levels and security obligations, the device configuration holds the mechanisms actually in place, and the logs or provider reports show whether those mechanisms performed. An assessor will expect these three sources to agree. A useful starting point is an inventory of every network service with its owner, its security requirements, its agreed service levels and the monitoring that checks them, and a confirmation with each provider of which reports and security information they will supply and how often. Confirm these details against your own contracts, because the wording varies between providers.

Which network services fall under A.8.21 and which scoping choices change the work

A.8.21 applies to every network service the organization relies on to protect information, whether it runs on its own hardware, sits in a cloud account it owns, or is bought from a provider. The scoping choice that changes the work most is who operates the service and who holds the logs, service levels and contract terms. Confirm each item against your own asset inventory and supplier register before you draw the boundary.

In-house network services

Firewalls, gateways, VPN concentrators, DNS resolvers, load balancers and internal certificate authorities that your own staff run in your data centers. These carry the full weight of A.8.21 because the organization sets the security mechanisms, service levels and requirements directly. Check that each service has a documented configuration, a named owner, and logs routed to a place where administrators cannot quietly edit them. Open-source options such as OPNsense for packet filtering and FreeIPA for internal certificates can produce that evidence, but the design decisions remain yours.

Externally provided carrier links

Leased lines, MPLS circuits, internet transit and site-to-site links bought from a telecom carrier. You cannot configure the carrier's core, so A.8.21 depends on what the contract promises: availability targets, time to restore, reporting of outages and the right to receive root cause summaries. Ask whether the carrier's service levels are contractual or only marketing material, and whether you receive the performance data you need to monitor them. Record these commitments in the supplier register so they feed A.5.22 supplier service monitoring.

Cloud network services in your accounts

Virtual networks, subnets, cloud firewalls, load balancers, private DNS and cloud VPN gateways that you configure inside cloud accounts you own. The provider runs the underlying fabric, but your team defines the security mechanisms and service requirements, so these remain your responsibility under A.8.21. Confirm which flow and access logs the provider makes available, how long they are kept, and whether they can be exported to your own monitoring. Infrastructure as code that declares these settings can serve as configuration evidence.

Managed and third-party security services

Managed firewalls, CDN and web protection, DDoS mitigation and managed DNS filtering operated by an external provider. The provider may run the platform, but the organization still needs to define what the service must block, who approves rule changes and how exceptions are recorded. Check whether the provider gives you its own logs, notification of incidents affecting your traffic, and the right to review its security practices. Without these terms, you will struggle to show monitoring of the service during an assessment.

Services that carry in-scope data

Any network path, from a corporate VPN to an API gateway, that transports personal data, financial records or other information your scope defines as sensitive. These paths need the same security mechanisms regardless of who operates them, because the consequence of a weakness is the data exposure itself. Use your data inventory to identify which services carry such data, then confirm that encryption in transit, access restrictions and logging apply end to end. This card is a filter that can apply to any of the others above.

Boundary with A.8.20 and A.5.22

A.8.20 Networks security covers how you secure and manage the network devices and networks themselves, while A.5.22 covers monitoring and review of what external suppliers deliver. A.8.21 sits between them: it asks that the service-level and security requirements of each network service are defined, implemented and watched. Map each network service to one owner under A.8.20 for the device and to one supplier record under A.5.22 where a provider is involved, so no service falls through the gap. Confirm this mapping against your own asset inventory before the assessment.

How an assessor tests A.8.21 and the findings they usually raise

This table compares four areas an assessor tests for A.8.21, showing the test approach, the evidence requested and the findings that appear most often. Read each row as a question the auditor will ask, then check whether your own records answer it before the audit starts. The main takeaway is that the requirement is not met by having a firewall or a provider contract alone; it is met when services, their requirements and their monitoring are documented and reviewed.

Test area	Test approach and evidence requested	Common findings
Identification of network services and requirements	Assessor samples network services and asks for the service inventory, the agreement or internal standard that sets each service's security and performance requirements, and the owner of each service.	Services in use are missing from the inventory, and requirements exist only in the head of an administrator or in a provider's marketing material.
Implementation of security mechanisms	Assessor selects sampled services and checks the configuration of firewalls, routing, encryption, access rules and aliases against the documented requirements, then compares the result with change records.	Firewall rules are undocumented or inherited from old projects, and configuration drifts from the standard with no change record explaining the difference.
Service levels and provider commitments	Assessor reviews contracts, service level agreements and the organization's own service level targets for network services, including managed carriers, cloud networking and hosted DNS, and asks when each was last reviewed.	Service levels were agreed at purchase and never reviewed, and no one can show which commitments the provider has actually met.
Ongoing monitoring and review	Assessor requests monitoring records for sampled services, such as availability and security alerts, and asks for evidence that someone reviewed them, acted on exceptions and fed results back into requirements.	Monitoring runs and produces alerts, but there is no review record, no named reviewer and no evidence that the findings changed the requirements.

Where A.8.21 stops and A.8.20 Networks security starts

A.8.20 governs the network itself, and A.8.21 governs the services that run on it. A.8.20 Networks security asks you to secure, manage and control networks and network devices: the documentation of the network, the hardening of routers, firewalls and switches, how administrators reach those devices, and how the network is monitored. A.8.21 Security of network services asks that the security mechanisms, service levels and service requirements of network services are identified, implemented and monitored, whether you run the service in house or buy it from an external provider. In practice the line is the service agreement. Internet access, managed WAN links, DNS, VPN concentrators, DDoS protection and cloud networking services each have security features, uptime commitments and reporting obligations that A.8.21 expects you to specify and check, while the firewall rules and device configurations behind them fall under A.8.20.

The two controls overlap in practice, which is why an assessor often tests them together. A firewall you operate is a network device under A.8.20, but if you rely on a provider's managed firewall or a cloud security group service, the provider's security features, change notification and service levels are also a network service under A.8.21. Ask which party configures, monitors and reports on each mechanism, and check that the Statement of Applicability reflects that split. Confirm where the supplier's responsibilities end, how you receive evidence such as configuration exports, incident reports and availability records, and who reviews them. An assessor will look for a single traceable answer to: what security is promised, by whom, and how you know it is delivered.

Cross-framework mappings can help you find starting points, but they are not proof of equivalence. NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.21 to CA-3 (Information Exchange) and SA-9 (External System Services), and NIST cautions that mapped controls are not always equivalent. ENISA's mapping for its NIS2 technical implementation guidance links A.8.21 to point 11.1 (access control policy) of the Annex to Commission Implementing Regulation (EU) 2024/2690. Non-NIST OLIR submissions map A.8.21 to CSF 2.0 subcategory PR.IR-01. Treat each as a lead to verify against your own service inventory, and confirm the mapping with your certification body or regulator before relying on it in evidence. The NIST OLIR catalog is the natural place to start that check.

How to implement A.8.21 in six steps and what each step produces

The sequence moves from knowing which network services exist, to defining and configuring the mechanisms and service levels that protect them, to watching those mechanisms over time and reviewing them. Each step ends with an artifact an assessor can examine.

Inventory the network services in scope
Start by listing every network service that carries or supports information within the ISMS scope. Include services run in house, such as VPNs, DNS, directory and remote access gateways, and services bought from external providers, such as carrier links, cloud networking and managed firewalls. Network engineers and service owners usually compile the list, and the asset owner confirms it. The step is complete when the inventory names each service, its owner, where it runs and which systems depend on it. The output is a network services inventory that the Statement of Applicability can reference.
Record security mechanisms and service requirements
For each inventoried service, document the security mechanisms that protect it, such as encryption in transit, access restrictions, packet filtering, authentication and certificate handling. Alongside them, record the requirements the business places on the service, including availability, permitted traffic and data classification. Ask the service owner and security team to sign off on the register. The output is a requirements register that links each service to its mechanisms and the risk entries that justify them.
Agree or confirm service levels with each provider
For services supplied by external providers, confirm in writing what the provider commits to: availability targets, incident notification, maintenance windows, security responsibilities and the evidence the provider will share. Compare these terms against the requirements register and record any gaps. Procurement, legal and the service owner typically handle this with the provider. The step is complete when signed or accepted service level terms exist for each external service. Where a service is in house, document internal service levels in the same format so the register stays consistent.
Implement and configure the mechanisms
Deploy the mechanisms named in the register and configure them against a written baseline. For self-hosted network components this can include stateful firewall rule sets with documented aliases, web application firewall rulesets, and certificate authorities that issue service certificates. Configuration should be version-controlled so changes can be traced. The engineering team applies the baseline, and a second person checks it. The output is configuration baselines and change records that show what was deployed, when and by whom.
Monitor mechanism health and service levels
Set up monitoring that shows whether each mechanism is working and whether each service meets its agreed levels. Typical signals include firewall rule match logs, certificate expiry alerts, availability metrics from providers and failed connection attempts. Define who receives each alert and what response is expected. The step is complete when alerts route to a named owner and a test event has been triggered and handled. The output is monitoring dashboards and an alert log that show service levels against the agreed targets over time.
Run a periodic review that feeds risk and management review
At planned intervals, review the inventory, the requirements register, provider performance and monitoring results. Record any service that has changed, any target that was missed and any mechanism that needs updating. Send significant findings into the risk register and carry the summary into the management review. Confirm that actions have owners and close dates. The output is a dated review record, updated risk register entries and minutes from the management review that an assessor can trace back to the original inventory.

Evidence that passes A.8.21 and how to keep it current between audits

An assessor testing A.8.21 wants to see that each network service is known, that its security needs are written down, that the provider commitments behind it are on file, and that the mechanisms are monitored and reviewed. The six artifacts below connect those points, and each one should be refreshed on the triggers that change it, not only at audit time.

Network service inventory with owners

A current register of every network service in scope, whether run in house or by an external provider, with a named owner, the systems it carries and the environment it sits in. The assessor checks that the list matches what is actually running, for example by comparing it against firewall rules, DNS records and cloud network configuration. Refresh it whenever a service is added, retired, moved or handed to a new provider, and review the whole list at each scheduled review cycle. Every entry should carry a date and the owner's name.

Requirements register per service

For each service, a record of the security mechanisms it needs (encryption in transit, access restriction, segregation, logging, availability targets) and the reason each one applies. Assessors look for a link from each requirement to the Annex A controls and the risk assessment that justified it. Update the register when the service's data classification, exposure or user base changes, and confirm it at each review. Avoid generic lists copied across services; the requirements should differ where the risk differs.

Provider service terms and internal agreements

Signed service level terms from external network providers, and internal service agreements between teams that run network services for each other. The assessor checks that the agreed security mechanisms, availability commitments and reporting duties appear in writing and that someone reviews performance against them. Store the executed version with its signature date and renewal date. Revisit the terms when the contract renews, when the provider changes its service, or after a material incident.

Configuration baselines and change records

Documented baseline settings for firewalls, load balancers, VPN gateways, DNS and cloud network controls, together with records of each change made to them. The assessor compares the current configuration with the baseline and samples change tickets to confirm that each change was requested, reviewed, tested and approved. Keep exported configurations under version control so that every difference is dated and traceable to a named change. Re-baseline after approved changes and check for drift between reviews.

Monitoring and alert records with review sign-off

Evidence that network services are monitored for availability, unexpected traffic and policy violations, including alert logs and the records showing who reviewed them and what action followed. Assessors sample alerts and ask for the sign-off trail, so an alert that fired without a documented response is a gap. Confirm that the log sources cover every service in the inventory and that log retention matches the retention rules set for the organization. Review monitoring scope whenever a new service is onboarded.

Periodic review minutes showing decisions

Minutes from scheduled reviews of network services that record what was examined, which findings were raised, who decided what and which actions remain open. Assessors read these to confirm that the review cycle works in practice and that decisions are carried forward, not merely noted. Each meeting should reference the inventory, requirements register, provider terms and monitoring records it examined, with a date and named attendees. Hold a review at the planned cycle and also after any incident or significant change to a service.

What meeting A.8.21 costs in money and effort

This table breaks down the money and staff time behind A.8.21 by cost component, showing whether each one is paid once or recurs, what drives it up, and how to keep it down. Read it as a checklist for building a quote, since no prices are given here and the largest recurring cost is usually people, not licenses.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Mostly recurring if commercial	Number of network services, firewalls, WAF and certificate tools in scope, and vendor license terms	Use open-source tools such as OPNsense, Coraza and FreeIPA where they fit, and confirm each tool's license terms in writing
Engineering time to inventory and configure services	One-time, with periodic updates	Number of internal and external network services, undocumented legacy links and how many service levels must be defined	Start from a single written inventory of services, owners and required service levels, then configure in phases
Staff time to run open-source tools	Recurring	Patching, rule reviews, certificate renewals and log handling, which stay with staff even when licenses are zero	Automate rule exports and certificate issuance where possible, and assign named owners for each mechanism
Provider review effort	Recurring	Number of external network service providers, contract reviews and how often their service levels are checked	Keep one register of providers, their service levels and review dates, and review the highest-impact providers first
Evidence upkeep	Recurring	Frequency of rule changes, log review cadence, and how many evidence records must be kept and retrieved	Export configurations and review records on a fixed schedule into one evidence store rather than assembling them before each audit
External testing or review of the mechanisms	Recurring or per engagement	Scope of testing, number of exposed services and whether results must be independently verified	Agree the testing scope and deliverables in writing before work starts, and reuse prior results where configurations have not changed
Auditor sampling effort	Recurring, once per audit cycle	Number of services and providers sampled, and how easily the team can produce records for each sample	Keep the inventory and provider register current so samples can be pulled quickly, and ask the certification body to confirm its sampling plan in advance
Quote preparation	One-time	How precise the written scope is about services, evidence and review cadence	Ask any implementation partner for a written scope listing the services, the evidence set, the review cadence and what the organization must provide

Which self-hosted open-source tools can support A.8.21 evidence

A.8.21 asks you to identify, implement and monitor the security mechanisms and service levels of network services. The four tools below each produce a different kind of evidence for that work: filtering configuration and logs, application-layer protection, certificate issuance records, and short-lived machine credentials. None of them decides whether your controls are effective, and each needs to be checked against your own architecture before you cite it in a Statement of Applicability.

OPNsense for network service filtering

OPNsense is a stateful packet filter (BSD-2-Clause) whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses for each network service, so the rule set reads as a register of which services are reachable and from where. Rule-match logging, viewed in the live log, can show that filtering operates as documented. Confirm that your rule export, change history and log retention meet the evidence needs your auditor will set, and that rules are reviewed against a documented service inventory.

Coraza for application-layer protection

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It is deployed in front of published services and integrates with Caddy, HAProxy, Traefik and Nginx. Its audit logs can document which requests were blocked for attack patterns such as SQL injection and cross-site scripting. Coraza is an application-layer control and does not replace network filtering. Confirm which rule set version you run, how rule changes are approved, and which services sit behind it.

FreeIPA for certificate issuance

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For A.8.21, this supports evidence that the services carrying network traffic use certificates issued under a controlled process, with records of who requested, approved and revoked them. Confirm that the CA hierarchy, certificate profiles, revocation procedure and key custody are documented, and that the CA is hardened and monitored as a critical service.

OpenBao for dynamic certificates

The OpenBao PKI secrets engine (MPL-2.0) issues dynamic X.509 certificates, so services receive certificates without an operator manually generating a key and certificate signing request. This shortens the window in which a compromised credential remains valid and produces a per-issuance record. Confirm the certificate time-to-live policy, which roles may request which names, how the root and intermediate keys are protected, and how issuance logs are retained and reviewed.

Who does what for A.8.21: your team, an implementation partner and the auditor

Your organization owns A.8.21. That means deciding which network services exist, which security mechanisms and service levels each one needs, and whether the arrangements still fit the business. The control covers services you run yourself and services that external providers deliver, so the inventory has to include both, along with the people who answer for each one.

Service inventory: Maintain a current list of network services, including internal services, carrier and connectivity services, cloud network services and managed services, with an accountable owner for each.
Service level decisions: Set the security requirements and service levels for each service, such as access restrictions, encryption, availability and logging, and record why they were chosen.
Provider management: Review provider contracts and service level terms, track provider reports and changes, and decide what to do when a provider misses a requirement.
Accepting residual risk: Decide which gaps are accepted, by whom and until when. This decision cannot be delegated to a partner or provider.
Periodic review: Check that the inventory, requirements and monitoring still match the environment and record the outcome as evidence.

Before engaging any outside party, confirm that your team can name the owner of every network service and the person who signs off each provider's service levels.

Questions buyers ask about A.8.21 cost, effort and outside help

How much effort does A.8.21 take for a small in-house network?

The effort depends mainly on how many network services exist and how many external providers operate parts of them. A small network with a few internal services, one internet connection and one hosting provider has far less to document, monitor and review than a network spread across several cloud accounts, colocation sites and managed circuits. The main drivers are the number of services, the number of providers, how often configurations change, and whether security mechanisms such as firewall rules, encryption and access controls are already documented. Most of the one-time work is building the inventory and agreeing the requirements for each service. The recurring work is reviewing that the mechanisms still work and that provider service levels are being met. Ask your team to size the inventory first, because that number drives most of the rest.

Can we meet A.8.21 without an outside consultant?

Yes, an organization can meet A.8.21 with its own staff if it has the skills to configure and review its network services and an accurate inventory of them. The control asks you to identify the security mechanisms, service levels and service requirements of each network service, implement them and monitor them. Internal teams usually struggle less with the technical configuration than with the paperwork: gathering provider contracts, agreeing service level expectations, and keeping records that show monitoring actually happened. An outside implementation partner can help prepare systems, configurations and evidence, but the organization still owns the control. Whether you bring in help should depend on the skills available in your team and the time you have before an audit.

What does the A.8.21 work need from our team?

The work needs named owners, read access to configurations, and access to the contracts that govern external providers. Assign an owner for each network service who can answer for its security mechanisms and requirements. Network and platform engineers need to provide firewall rules, routing and access configurations, certificate and encryption settings, and monitoring outputs. Procurement or legal staff need to supply provider agreements, including service levels, support commitments and reporting duties. A compliance lead should keep the register of services and evidence current. Without these inputs, the team will spend most of its time chasing information rather than improving controls, so confirm access before work starts.

How long does A.8.21 take to put in place?

The timeline depends on the scope: how many network services and providers are involved, how mature the existing documentation is, and how many approvals are needed. A narrow scope covering one environment can move quickly, while a scope spanning several cloud accounts, data centers and third-party providers takes longer because each service needs its requirements agreed and its monitoring checked. Delays often come from waiting for provider responses and from gaps in the inventory. Ask any partner or internal project lead for a written timeline that lists the services in scope, the deliverables for each phase, and the dependencies on other teams or providers. A timeline without a defined scope is not a basis for planning.

Can a consultant certify that we meet A.8.21?

No. A consultant or implementation partner can prepare your network services, configurations and evidence, but only an independent certification body can certify your management system against ISO/IEC 27001. ISO itself does not certify organizations, and accredited certification bodies run the audit and issue the certificate. An assessor will test whether the mechanisms are implemented and monitored and whether the evidence supports it. Be cautious with any provider that promises a certificate or a pass result. Ask who will conduct the audit, confirm that the certification body is accredited, and check the certificate in the IAF CertSearch database, which ISO points to for accredited certificates.

What should we confirm about provider service levels before the audit?

Confirm that each external provider's service levels, security commitments and reporting duties are written down, current and matched to your own requirements for the service. An assessor will look for the service requirements you set, the provider's commitments against them, and evidence that you monitor performance. Check whether the contract covers availability, incident notification, change notice, log or report access, and the right to review. If a provider's commitments do not reflect your requirements, record the gap and your decision on it. Also confirm who receives provider reports, how often they are reviewed, and what happens when a service level is missed. Gaps found in this review are much easier to address before the audit than during it.

How DeployOpen scopes, implements and prepares A.8.21 evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the network services behind A.8.21 Security of network services. We prepare the systems, configuration records and evidence that an independent auditor will test, while your organization keeps ownership of the control and its decisions.

How we scope

We list the network services in scope, including in-house and externally provided services, and record who owns each one.
We agree the security mechanisms, service levels and service requirements to be documented for each service before work starts.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build work begins.

How we build

We configure and harden the network security mechanisms you approved, such as packet filtering rules and certificate issuance, in your environment.
We set up monitoring and logging for those mechanisms so that rule matches and service changes can be reviewed later.
We run security testing against the configured services and record the findings and fixes for the evidence file.

How we hand over

We document the service requirements, configured mechanisms and review procedures in a form your control owners can maintain.
We provide the evidence set an assessor would ask for, such as rule exports, change records and monitoring reports, with clear locations.
Your organization and any independent auditor decide whether the control is effective. DeployOpen prepares the material only.

How we support

Ongoing support, upgrades and continuous testing of the network services are available as a retainer.
We can review monitoring output and service changes on a schedule agreed in the written scope.
Ask any implementation partner to confirm in writing which review and evidence tasks sit inside the retainer and which stay with your team.

A.8.21 Security of network services