Safeguard 12.2 Secure network architecture guide

Secure network architecture under Safeguard 12.2 is a design and policy obligation

Safeguard 12.2 asks an organization to design and maintain a secure network architecture that addresses, at minimum, segmentation, least privilege and availability. An auditor or customer who asks for it is checking whether you have decided how your network should be divided, who and what may cross each boundary, and how the network keeps running under stress, and whether those decisions are written down, owned and kept current. A set of network diagrams shows what exists. It does not show why it was built that way or what rules govern changes to it, and that gap is where many teams fail this requirement.

The risk is easy to state. A flat network, where a workstation, a payment server and a building controller can all reach each other, lets an attacker who compromises one device move laterally to the rest. Unmanaged networks also drift: rules accumulate, exceptions never expire and nobody can say which segment a new server belongs in. Safeguard 12.2 applies to Implementation Group 2 and 3 enterprises, not to IG1 organizations, and it sits in the Network asset class under the Protect security function. Confirm your own Implementation Group before scoping effort, because an IG1 organization may not be held to this Safeguard at all.

The hard part is the design work, not the drawing. Someone has to decide the segments and their purpose, the default deny posture between them, which services may cross each boundary, how administrative paths are isolated and what availability target each segment must meet. The assessment specification expects a software inventory (Safeguard 2.1) and an architecture diagram (Safeguard 12.4) to exist as prerequisites, so the design has to start from known assets and be recorded in a form that can be reviewed. Ask your team or any outside partner to produce a written architecture decision record, a segment register and a rule review schedule, and treat a diagram without those as incomplete.

Which networks and teams fall under the secure network architecture scope

Safeguard 12.2 applies to IG2 and IG3 enterprises, not IG1. The scope you set determines how many network segments must be designed, how many teams must agree on those designs, and how much evidence the assessment will ask for. The cards below cover the decisions that change that workload most.

Network segments and environments

Start by listing every network segment that carries enterprise data or supports critical services: production, corporate user networks, cloud VPCs, development and test, and any OT or out-of-band management networks. The CIS assessment specification scores 12.2 as the share of network segments implementing least privilege and the share monitored for availability, so the denominator is your segment list. An incomplete list makes the score look better than the environment is. Confirm the list against your 12.4 architecture diagrams and your asset inventory before you count.

Enforcement points and platforms

Identify every device or service that enforces segmentation: firewalls, routers, layer 3 switches, cloud security groups and network access rules. A segment is only as protected as the enforcement point in front of it, so each segment should map to a named enforcing platform and a documented rule set. Where a segment is enforced by more than one layer, record which layer owns the policy. Mixed estates, such as on-premises firewalls plus cloud security groups, usually add the most reconciliation work.

Teams that own design decisions

Network architecture usually spans network engineering, security, cloud platform, and application owners. Decide who approves a new segment, who may change a trust boundary, and who signs off on exceptions to least privilege. The safeguard expects design and policy, so an architecture that one engineer knows but no governance body has approved will be difficult to defend. Write down the approval path and the roles, and confirm they match how changes actually get made.

Third-party and managed networks

Networks run by a managed service provider, a cloud host or a partner connection can still carry your data and touch your segments. Decide whether each one sits inside your architecture, is a boundary you connect across, or is excluded with documented reasoning. Where you depend on a provider for segmentation, obtain the provider's design documentation and contractual responsibilities in writing. Control 15 covers provider oversight in more depth, so align the two reviews.

Scope choices that change the workload

Some choices multiply effort: including OT or management networks that were never segmented, counting many small cloud accounts separately, or treating every development environment as in scope. Narrowing scope can be legitimate when a boundary is documented and enforced, but an assessor will ask how the excluded segments are isolated. Ask any implementation partner for a written segment inventory and a per-segment effort estimate before work starts, so scope changes are visible early.

Applicability by Implementation Group

Safeguard 12.2 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1 organizations. If you are an IG1 organization, your Control 12 obligation is the patch currency safeguard. If you are IG2 or IG3, confirm your Implementation Group in writing with your internal owner before you size the scope. Organizations that adopt the Controls voluntarily often choose a higher group than required, which changes the list of segments that must be assessed.

Why a diagram alone does not satisfy the architecture safeguard

Safeguard 12.2 asks for a secure network architecture to be designed and maintained, and CIS states that implementations should include policy and design components rather than documentation alone. In practice, the architecture has to answer four questions in writing: how network segments are chosen and what each one is for, what traffic is permitted between segments, who approves changes to those boundaries, and how availability is designed into the topology. A drawing that shows boxes and lines answers none of these on its own. An assessor will look for the rules and decisions behind the picture, such as the segmentation policy, the criteria used to place a system in a segment, and the approval path for a new trust boundary or a changed firewall rule.

The architecture safeguard and the documentation safeguard are separate jobs. Safeguard 12.2 covers the design itself and the governance around it: the principles, the approved patterns, the owner of each segment, and the review that happens before a change goes live. Safeguard 12.4 covers the diagrams and system documentation that record the result, with its own annual review cycle. An organization can pass a documentation review with accurate diagrams while still having no decision record explaining why a segment exists or who may change it, and that gap is what 12.2 is meant to close. Keeping the two apart also tells the reader where evidence lives: decision records and policy for 12.2, versioned diagrams for 12.4.

For the assessment, the CIS Controls Assessment Specification measures 12.2 through the share of network segments that implement least privilege and the share of segments monitored for network availability, and it names Safeguards 12.4 and 2.1 as prerequisites. That means a segment inventory must exist before anyone can count segments, and the software inventory must be current enough to show what runs inside each one. Confirm with your assessor exactly how they will count segments and what evidence they accept for monitoring. The CIS Controls Assessment Specification sets out the measures, and it is the right reference to bring to that conversation before the design work starts.

How an assessor tests secure network architecture

This table sets out what an assessor checks for Safeguard 12.2, the evidence each check expects and the findings that usually come up first. Read it as a preparation checklist: the prerequisites must be in place before the two CIS metrics can be measured credibly.

Test area	What the assessor checks	Evidence requested	Common findings
Prerequisite: architecture diagrams (12.4)	Whether current diagrams exist that show every network segment the design relies on	Versioned diagrams with a review date and owner, matched against the live segment list	Segments in production that appear on no diagram, or diagrams last reviewed before the latest design change
Prerequisite: software inventory (2.1)	Whether the applications and services placed in each segment are known	Software inventory export mapped to the segment or zone each system sits in	Systems running in a segment with no inventory entry, which makes least privilege impossible to judge
Policy and design review	Whether a written network architecture policy and design exist and drive segmentation choices	Approved policy, design rationale per segment, and records of exceptions with approval	Design documents that describe intent but have no policy behind them, or designs that were never signed off
Metric: least privilege share	The proportion of network segments where traffic is limited to what each segment needs	Firewall or segment rule exports, with a count of segments that enforce a default-deny position and a list of allowed flows	Broad any-to-any rules left from a flat network, or rules that predate the current design and were never removed
Sampling of segment rules	Whether rule sets in a sample of segments match the documented design and the stated purpose of each segment	Rule sets for sampled segments, change tickets linked to rule edits, and the design rule each entry is meant to support	Rules with no owner or business reason, allowed ports with no documented service, and admin paths reaching production segments
Metric: availability monitoring share	The proportion of network segments monitored for availability	Monitoring configuration showing which segments are polled or alerted, with alert history for a sample period	Segments that are designed and firewalled but absent from monitoring, so outages there go unnoticed
Availability design	Whether the design accounts for resilience of key paths and services, not only access control	Redundancy or failover design for critical segments and test or review records showing the design was checked	Single points of failure in critical segments that the design does not mention
Change alignment	Whether changes to segments and rules follow the same design and approval process	Change records that reference the design, and reviews confirming the design was updated after changes	Design documents that stopped tracking changes made after an incident or urgent request

Implementing secure network architecture step by step

This sequence turns Safeguard 12.2 from a diagram into a designed, enforced and reviewed architecture, with each step leaving an artifact that an assessor can trace back to the Safeguard.

Inventory network segments and the software that depends on them
Start by listing every network segment, the systems and applications placed in each one, and the software those systems depend on. This step draws on the software inventory required by Safeguard 2.1, which the CIS Controls Assessment Specification names as a prerequisite for measuring 12.2. The network team and application owners work together so that no segment is defined without knowing what runs inside it. The output is a segment register that links each segment to its owner, its assets and its dependent software. The step is complete when every segment in scope has an owner and a listed set of dependencies.
Document the architecture as the baseline
Record the segment register in the architecture diagrams and supporting network documentation required by Safeguard 12.4. The diagrams give the design a shared reference point, but they describe the design rather than prove it. The network architect confirms that each segment, trust boundary and path between segments appears in the documentation and matches the register. The output is a versioned architecture baseline with a named owner. Diagrams alone do not satisfy 12.2, so this baseline becomes the input to the policy and design work in the next steps.
Define segmentation and least privilege policy
Write the policy that sets how segments may communicate. It should state the purpose of each segment, the default deny posture between segments, which flows are permitted and why, and who approves exceptions. Least privilege applies to both users and systems, so the policy limits each segment to the ports, protocols and destinations its function requires. The output is an approved network segmentation policy and a rule set that maps each permitted flow to a business justification. The policy is the component that makes the architecture more than a drawing, and it is the item an assessor will look for first.
Design availability and monitoring for each segment
For each segment, define how its availability is protected and how that availability is observed. Consider redundant paths and devices for critical segments, capacity expectations, and the monitoring that will show when a segment becomes unreachable or degraded. The CIS Controls Assessment Specification scores 12.2 with an availability metric based on the share of network segments monitored for network availability, so every segment needs a monitoring target. The output is an availability and monitoring design per segment, showing the monitored segments and the alerts that cover them.
Implement and verify enforcement
Configure firewalls, routers and access control so that the approved policy is enforced on the live network, not only described in documents. Rules should be expressed through aliases or address groups where possible so that changes can be traced to the policy. Verification means testing that permitted flows work and that denied flows are blocked, then keeping the rule logs or test results. The output is a configuration export or rule set, a test record for each segment boundary, and any logging enabled for rule matches. Open-source firewalls such as OPNsense can record each rule match, which helps show enforcement over time, but the organization should confirm the logging and retention meet its own requirements.
Set the review cycle and change control
Decide how often the segment register, policy, rule set and availability metrics are reviewed, and tie every architecture change to an approval and an update of the baseline. Changes that bypass the baseline are the most common reason an architecture drifts from its design. Change records, review minutes and version history of the policy and diagrams become the ongoing evidence that 12.2 is maintained. Ask the assessor and any implementation partner to confirm the review frequency and the change process in writing before the first formal assessment.

Evidence that shows secure network architecture is in place

An assessor testing Safeguard 12.2 looks for a design that exists on paper and is enforced in the network. The cards below connect the approved design, the rules that enforce it, the segment inventory, availability monitoring, design review records and periodic reviews, so each piece can be traced to the others.

Approved architecture design and policy

The written network architecture design and the policy behind it, with a version number, an owner and a dated approval record. The policy should state the segmentation approach, the least privilege principle applied to traffic between segments, and the availability requirements each segment must meet. Check that the approved version matches the one in use and that the policy names who may approve exceptions. Because Safeguard 12.2 expects policy and design rather than diagrams alone, this card is the anchor for the rest of the evidence.

Segmentation and least privilege rule export

Rule sets exported from each enforcement point, such as firewalls, routers and segment gateways, showing which sources may reach which destinations, ports and protocols. An assessor compares these rules against the approved design and looks for broad any-to-any rules that bypass segmentation. For OPNsense, aliases and per-rule logging help show that each rule maps to a stated business purpose. Export the rules with a timestamp and keep the export tied to the configuration version it came from.

Segment inventory mapped to the architecture

A list of every network segment, with its purpose, address range, data classification, owner and the enforcement point that controls it. Each entry should trace to a segment on the architecture design. Gaps matter in both directions: a segment in production that is missing from the design suggests the design is out of date, and a design segment with no live counterpart suggests it was never implemented. This inventory is also the denominator for the Least Privilege and Availability metrics, so its completeness determines the score.

Availability monitoring coverage per segment

Evidence that each segment is monitored for availability, with the monitoring tool, the check interval, the alert recipients and a recent sample of alerts or dashboard exports. Assessors use this to test the Availability metric, which measures the share of segments that are monitored. Confirm that monitoring covers segments that carry critical services, not only the ones that are easy to reach, and that alerts route to people who act on them. Record any segment deliberately excluded and the reason.

Design review change records

Change tickets or merge requests that show the architecture was reviewed before a segment was added, a rule was opened or a route was changed. Each record should name the reviewer, the security sign-off and the link to the updated design version. Sample changes across the period under audit. A change that altered segmentation with no design review record is a finding, and so is a review that approved a change the enforced rules do not reflect.

Periodic architecture review record

Minutes or a signed record from a scheduled review of the architecture, covering the segment inventory, the rule sets, availability results and open exceptions. The record should show who attended, which decisions were taken and which actions remain open with owners and dates. Keep the review on a fixed cadence set in the policy, so an assessor can confirm the design was checked after it was approved and not only when it was first written.

What meeting Safeguard 12.2 costs in money and effort

This table breaks down the cost components of meeting Safeguard 12.2, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal work against outside help and to frame the questions you ask in a quote. No dollar figures are shown because none are supplied for this Safeguard.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Architecture design and policy work	Internal network and security engineers, with optional outside design support	One-time to establish, recurring to review	Up: number of segments and zones, undocumented legacy flows. Down: a current software inventory (Safeguard 2.1) and an existing diagram (Safeguard 12.4)
Segmentation and firewall tooling	Licensed vendors or internal staff; self-hosted open-source firewalls such as OPNsense remove license spend where the platform fits	Licensing recurs; hardware and rule build-out is one-time	Up: commercial feature sets, high-availability pairs, vendor support tiers. Down: open-source platforms run in your own infrastructure, though you carry the staff time to operate them. Confirm platform capabilities against your requirements
Availability and network monitoring	Internal operations staff, plus any monitoring product licensing	Recurring	Up: number of segments that need availability checks and alert routing. Down: reuse of monitoring already covering Control 13 and Control 8 logs
Least privilege rule reviews	Internal network and security staff	Recurring	Up: rule count, any-to-any rules, shared service accounts. Down: alias groups, documented owners for each rule, and scheduled recertification
Evidence upkeep	Internal compliance or engineering staff	Recurring	Up: manual exports and screenshots, many owners. Down: version-controlled design records and rule logs kept in one place, such as a wiki or document system with version history
External design review or penetration testing	Independent consultants or testing firms, paid per written scope	Typically one-time or periodic	Up: complex hybrid or cloud estate, many segments to test. Down: a fixed scope agreed in writing before work starts. Ask for scope, deliverables and timeline in the quote
Auditor sampling time	Independent auditor or assessor, paid by the organization being assessed	Recurring with each assessment cycle	Up: number of segments sampled and missing evidence. Down: a complete evidence set per segment that is ready before fieldwork begins

Open-source tools that produce secure network architecture evidence

Safeguard 12.2 is judged on whether segmentation, least privilege and availability are designed, documented and operating, so the evidence has to come from the systems that enforce them. The four tools below each produce one part of that record: enforced traffic rules, protected service entry points, versioned design and policy pages, and role-controlled documentation. Confirm fit against your own environment and licensing review before adopting any of them.

Firewall rules and rule logs

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses by segment, so the rule set can be read against the segment model rather than against individual hosts. Enable logging on each rule that enforces a segment boundary, then review the live log view and export the rule configuration as part of the evidence set. Confirm that the rule set matches your documented segment design, since the assessment checks whether segments actually enforce least privilege.

Web application filtering at segment edges

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends against attacks such as SQL injection, cross-site scripting and code injection, and has integrations for Caddy, HAProxy, Traefik and Nginx. Place it where web services face another network segment, and record which ruleset version is loaded and which services it protects. Confirm that the rulesets you choose are maintained, and that the proxy you integrate with is one your team already operates.

Versioned architecture and policy pages

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one. Store the segmentation policy, the design rationale for each segment and the availability targets here, so an assessor can see when a design decision was made and who approved the change. Check whether the LGPL terms fit how you plan to modify or distribute the platform, and have counsel confirm the position if you embed it in a product.

Role-based documentation permissions

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets network architects edit segment designs while auditors and operations staff hold read-only access to the same material. Map each role to the people who are accountable for a segment, and export the role assignments on a set schedule. The MIT license is permissive, but confirm that the role model covers your separation of duties before relying on it as evidence of controlled access.

Who does what for secure network architecture

Your organization owns the network architecture. Safeguard 12.2 asks for a secure network architecture to be designed and maintained, and the design has to reflect decisions your leadership can explain and defend. Those decisions cover how the network is split into segments, which trust levels each segment carries, who may reach which segment, and how availability is protected. An implementation partner can draft these, but the accountable owner must review, approve and adopt them.

Architecture decisions: Set the segmentation model, the trust zones and the default deny posture for traffic between them.
Policy approval: Approve the written network architecture policy that gives the design its authority and sets review intervals.
Segment ownership: Name an owner for each segment who answers for its rules, its exceptions and its availability targets.
Enforcement: Run the firewall, switch and cloud security group change process so that rules match the approved design.
Exceptions and change control: Record every rule exception with a reason, an approver and an expiry date.

Before engaging anyone, confirm that a named executive has signed the architecture policy and that each segment has an owner who can explain its rules without reading the vendor manual.

Where organizations fall short on secure network architecture

Most gaps under Safeguard 12.2 come from a design that exists on paper but is not enforced, measured or kept current. The cards below cover five recurring shortfalls, each paired with the fix an assessor will expect to see evidenced.

Diagrams without an approved design policy

Teams often have a network diagram but no written policy that sets how segments are created, who approves changes and which traffic is allowed between zones. Safeguard 12.2 expects policy and design components, so a diagram alone does not show that the architecture is intended and governed. Fix it by adopting a short network architecture policy that names the owner, the approval path and the review cycle, then tie each segment in the diagram to that policy. Check that the policy is signed off by someone accountable for network risk.

Segments without least privilege rules

A segment that exists but permits any-to-any traffic does not implement least privilege, even if it is labeled as isolated. The CIS assessment specification scores this as the share of network segments implementing least privilege, so every segment needs an explicit allow list. Fix it by writing rules from each segment's stated purpose, starting with the flows that the application owners can justify, and denying everything else by default. Review rule counts per segment to spot rules that were added and never removed.

Availability not measured per segment

Availability is often tracked for the whole network, which hides a segment that has been down or degraded for weeks. The assessment specification asks for the share of network segments monitored for availability, so coverage must be counted segment by segment. Fix it by listing every segment in the architecture, assigning a monitor to each, and recording which segments have no monitor yet. Ask whether a monitoring gap would be noticed before a business service fails.

Rules drifting after emergency changes

Emergency firewall openings made during an incident are frequently left in place after the incident closes, and the live rule set then departs from the approved design. This erodes segmentation without anyone deciding to weaken it. Fix it by requiring each emergency change to carry an expiry date and a reference to the incident, then reconciling live rules against the design at each review. Keep the change history so an assessor can see who approved each exception.

Software dependencies missing from the inventory

Segmentation decisions depend on knowing which applications talk to which services, yet many software inventories do not record those dependencies. Without them, a segment boundary can break a business process or leave a hidden path open. Safeguard 2.1, the software inventory, is a prerequisite for measuring 12.2, so the gap blocks the assessment itself. Fix it by recording each application's network dependencies in the inventory and mapping them to the segments that host them before changing any boundary.

Questions buyers ask about Safeguard 12.2

Does Safeguard 12.2 apply to IG1 organizations?

No. Safeguard 12.2 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. IG1 covers essential cyber hygiene, and its only Control 12 Safeguard is 12.1, which concerns keeping network infrastructure on supported, current software. An IG1 organization can still design a segmented network, and doing so is good practice, but the CIS Controls do not ask it to measure 12.2. If you are unsure which Implementation Group applies to you, confirm it against the CIS Implementation Groups pages and your own risk profile before scoping the work.

How much effort does a secure network architecture take, and what drives it?

The effort depends mostly on how many network segments exist, how many of them are documented against a clear purpose, and how much of the estate runs in several clouds or data centers. Work usually falls into three parts: agreeing the architecture principles and policy, mapping the current segments and their trust levels, and correcting gaps in least privilege and availability. Organizations with a small, stable network need far less than those with legacy flat networks, overlapping cloud accounts or many third-party connections. Ask any provider for a written breakdown of these parts and the systems in scope before accepting a figure.

Can our own team implement Safeguard 12.2 without outside help?

Often yes, if you have network architects who own the design and staff who can change firewall and cloud routing rules. The harder part is usually evidence: writing the policy, keeping the design current, and measuring least privilege and availability across segments in a repeatable way. Outside help is most useful when the team lacks time, when the estate is spread across several platforms, or when an assessor will test the work soon. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure and prepares systems and evidence for assessments, but it does not issue reports or certificates. Your team still owns the controls.

What does the work need from our staff and systems?

Plan for three inputs. First, named architecture owners who can make and approve segmentation decisions and sign off the policy. Second, read and change access to firewall, routing and cloud network configuration, ideally through version-controlled exports so changes can be traced. Third, time with the assessor or internal auditor to walk through the design and the metrics. The prerequisites in the assessment specification also include a software inventory (Safeguard 2.1) and an architecture diagram (Safeguard 12.4), so those owners will need to contribute there too. Confirm access arrangements and review windows in writing at the start.

How long does it take to get a secure network architecture in place?

The timeline depends on scope: the number of segments, the number of environments, how much of the current design is undocumented, and how many approvals the change needs. A single data center with a documented design can move much faster than a multi-cloud estate with legacy flat networks. No fixed duration applies here. Ask for a timeline tied to a written scope, with milestones for policy approval, design review, configuration changes and evidence collection, and note which milestones depend on your change advisory board or on an assessor's calendar.

Does a network diagram alone satisfy Safeguard 12.2?

No. CIS states that implementations of Safeguard 12.2 need policy and design components, not documentation alone. A diagram records the network as it is. Safeguard 12.2 asks you to design and maintain a secure architecture that addresses segmentation, least privilege and availability, backed by a policy that says how segments are created, what trust levels they carry and how exceptions are approved. Diagrams are a separate requirement under Safeguard 12.4, and they support 12.2 without replacing it. Expect an assessor to ask for the policy, the design rationale and the configuration that enforces it.

Do the CIS Controls require certification, and who issues the report?

The CIS Controls do not require certification. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, and the Controls content is free for organizations to use to improve their own security under its license terms. If a customer or regulator asks for evidence against Safeguard 12.2, an independent assessor or certification body issues any report or certificate. DeployOpen prepares systems, controls and evidence for those assessments, but it does not issue audit reports, attestations or certifications. Confirm with the requesting party which assessment type they accept before starting.

How DeployOpen prepares secure network architecture evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the network architecture behind Safeguard 12.2 is designed and evidenced in the environment that will be assessed. Engagements are fixed-scope, and the organization keeps ownership of its controls while DeployOpen prepares the systems, policy and evidence an independent assessor will review.

How we scope

Agree in writing which network segments, zones and administrative paths fall within the Safeguard 12.2 scope.
Confirm the architecture diagram and software inventory prerequisites from Safeguards 12.4 and 2.1 before design work starts.
Define the least privilege and availability measures the organization will report for each network segment.

How we build

Design segmentation between zones so that traffic is allowed only where a documented business need exists.
Configure firewall rules with aliases, named groups and logging of rule matches so each permitted path can be traced.
Document the architecture policy and design decisions alongside the technical configuration, not as diagrams alone.

How we hand over

Deliver the written architecture policy, design records and segment-by-segment configuration as version-controlled documentation.
Provide evidence packs that show segment ownership, rule justifications, monitoring of segment availability and review dates.
Confirm with the organization and its assessor which evidence format and retention period they require before handover.

How we support

Offer ongoing support as a retainer for reviewing segment changes, rule drift and evidence currency after handover.
Re-run architecture reviews when new segments, platforms or service providers are added to the environment.
Ask the assessor early which metrics and sampling they will use, so the evidence matches how the control is tested.