Safeguard 9.1 supported browsers and email clients

What Safeguard 9.1 asks for and why it is harder than it looks

Safeguard 9.1 asks for one thing: only fully supported browsers and email clients may run in the enterprise, and only at the latest version the vendor supplies. The difficulty is that most organizations cannot state, with confidence, which browsers and mail clients are installed, which versions they run, or whether a vendor still supports them. Browsers and mail clients are a common entry point for web and email attacks, and an unpatched or out-of-support build stays exposed after the vendor stops issuing fixes. Within CIS Controls v8.1, Safeguard 9.1 sits in the Software asset class and the Protect security function, and it belongs to Implementation Group 1 as essential cyber hygiene, so a minimum-standard enterprise is expected to meet it.

The hard part is knowing what is installed before judging support status. Browsers and mail clients are often installed by users, bundled with other applications, or carried on laptops that rarely join the corporate network, so a list built from directory or patch tools will miss them. Start by confirming that the software inventory required by Safeguard 2.1 covers browsers and mail clients on managed and unmanaged devices, including remote laptops and bring-your-own-device enrollments. Then confirm, with each vendor's published lifecycle page, which versions are still supported and which build is current. Self-hosted tools such as GLPI and Wazuh can collect this data, but whether they see every device in your environment depends on your agent coverage, which you should verify rather than assume.

Ask who owns the decision to block an unsupported build. Under Safeguard 9.1 the enterprise must enforce the rule, so someone must own the allowed version list, the exception process for a business application that needs an older client, and the timeline for removing it. Put that ownership in writing before measuring, because the Assessment Specification for v8.1 measures the percentage of unsupported browser and email client software in use, along with false positive and false negative rates for the detection method. An inventory that produces many false negatives will understate the problem, and an assessor will ask how you tested it.

Which browsers, mail clients, devices and teams fall under Safeguard 9.1

Safeguard 9.1 applies to whatever the enterprise treats as an enterprise asset, so the first work is deciding which devices, virtual desktops, servers and users sit inside that boundary. Each card below is a scoping decision that changes which browsers and mail clients must be checked against their vendor's supported versions.

Enterprise-owned and personal devices

Company-issued laptops and phones are usually in scope by default. Personally owned devices that open corporate mail or sign in to web applications need a written decision: either they are enterprise assets and must be inventoried and checked, or access is limited to managed containers or web sessions that the enterprise controls. Ask who approves a bring-your-own-device rule and whether that rule matches what the inventory actually records.

Virtual desktops and published apps

A browser or mail client running inside a virtual desktop or published application is still running in the enterprise. Decide whether the image, the session host or the client version is the asset you measure. If a single golden image serves many users, one outdated browser build can affect every session, so the image itself needs to be in the software inventory.

Servers that run browsers or mail clients

Some servers host reporting tools, scanners, kiosk displays or automation jobs that launch a browser or a mail client. These processes are easy to miss because no one signs in to them as a user. Confirm whether each server is in scope, which binaries it runs, and whether the same support rules apply to headless or scripted use.

Users on remote and unmanaged networks

Staff working from home, travel or partner sites use the same browsers and mail clients, but they may not pass through corporate proxies or patch channels. The scope should state that the requirement follows the device and the user, not the office network. Check how the inventory agent reports from outside the corporate network and how stale records are flagged.

Bundled and embedded browser engines

Many business applications ship their own embedded browser engine, such as a Chromium or WebView component inside a desktop app or an email plugin. Decide whether the engine counts as a separate browser for Safeguard 9.1 or as part of the application. Record the engine version as its own inventory item, because it can lag the standalone browser that users update.

Decision owners and inventory mapping

Name who decides what counts as an enterprise asset, usually the CISO or IT asset owner, and who maintains the mapping from the CIS Controls Assessment Specification Software asset class to the asset inventory. Safeguard 2.1 is a prerequisite for measuring 9.1, so the software inventory must carry the same asset boundary. Write the decision down so an assessor can trace each measured browser or mail client to an owned asset.

How an assessor tests Safeguard 9.1 against the CIS Assessment Specification

This table sets out what an assessor takes in, measures and asks for when testing Safeguard 9.1, row by row. Read it as a checklist of the evidence to have ready before fieldwork starts, because the Assessment Specification defines what to measure but leaves the method to the organization.

Test element	What the assessor examines	Evidence to prepare	Common findings
Input: software inventory (Safeguard 2.1)	Whether a complete software inventory exists to serve as the population for browser and email client checks	Exported inventory with fields for name, version, publisher and install location, plus its last update date	Inventory older than the endpoints it describes, or browsers and mail clients missing from it
Measure: browser and email client population	The set of browsers and email clients in use across managed and unmanaged endpoints	Scoped list of in-scope endpoint groups and the browser and mail client products each group runs	Scope limited to corporate laptops, leaving virtual desktops, servers and personal devices unexamined
Measure: support status per product	Whether each installed version is still supplied by its vendor and is the latest version the vendor provides	Vendor support or end-of-life references used, with the date each reference was checked and who checked it	Support dates taken from memory or secondary sites instead of vendor documentation
Metric: percentage of unsupported software in use	The share of observed browser and email client installations that fall outside vendor support	Calculation worksheet showing numerator, denominator and the method used to count installations	Counts that mix installations with users, or that exclude portable and side-loaded copies
Metric: rate of false positives	Whether flagged software is wrongly reported as unsupported or out of scope	Sample of flagged items with the reviewer's verdict and the reason for each reclassification	No sampling performed, so inventory errors go unnoticed
Metric: rate of false negatives	Whether unsupported software is missed by the detection method	Independent comparison against a second source, such as a network or endpoint scan, with results recorded	Reliance on a single source that cannot see shadow installations
Shadow installations	Whether browsers or mail clients installed outside standard deployment are discovered and assessed	Procedure for finding user-installed and portable software, and records of what it found	Standalone browser builds or webmail-adjacent clients never reached by the inventory tool
Organization's documented method	Whether the organization can explain how it measures, since the specification does not prescribe the method	Written procedure covering data sources, frequency, roles, thresholds and exception handling	Measurements produced but no description of how they were taken, so the assessor cannot reproduce them

How to implement Safeguard 9.1 in the order an assessor will check it

This sequence moves from the software inventory to a measured, falling rate of unsupported browsers and email clients, with a dated record at each stage that an assessor can sample. Each step produces a file or report you can hand over as evidence.

Confirm the Safeguard 2.1 software inventory covers browsers
Start with the software inventory required by Safeguard 2.1, which the CIS Controls Assessment Specification lists as a prerequisite for measuring Safeguard 9.1. Check that every in-scope device, including laptops used remotely, reports every installed web browser and email client, with product name, version and publisher. Compare the inventory against an endpoint sample to find gaps, such as browsers installed per user profile or portable builds. Done means the owner signs off a reconciliation report showing the inventory matches the sampled endpoints. Open-source options such as GLPI Assets or Wazuh Syscollector can supply this data, but you should confirm that each collects browser and mail client entries in your environment.
Record vendor support status for each product
For every browser and email client in the inventory, record the vendor's support status and the latest version the vendor currently supplies. Assign the product owner, typically the endpoint or application team, to maintain this baseline and to say where each version figure came from. Confirm the vendor's own lifecycle pages rather than relying on memory or third-party lists. Done means a versioned support baseline exists, with a named owner and a review date, that an assessor can compare against the inventory. The baseline is the reference for every later measurement.
Compare installed versions against the baseline
Match each inventory record to the support baseline and classify it as current, behind on a supported branch, or unsupported. Use the matching logic in your inventory or endpoint tool, and keep the query or rule that produced the classification so it can be rerun. Review a sample of flagged and unflagged records by hand to confirm the logic is correct. Done means a classified list exists for every in-scope device, with the query saved in version control. This list is the source for the percentage of unsupported software that the assessment specification measures.
Block or flag unsupported versions through endpoint management
Route unsupported browser and email client versions into the endpoint management process. Where your platform can enforce, configure it to block launch or to prompt for update. Where it cannot, flag the device for a ticketed update through the standard change process. Assign each flag to an owner and record the action taken. Done means policy configuration exports, deployment records and tickets exist for flagged devices, which together show the control is enforced, not just reported. Confirm with your endpoint vendor which enforcement options apply to your products.
Set a remediation window and exception process
Document the time allowed to update a flagged browser or mail client, and the approval path for devices that cannot update, such as legacy line-of-business systems that depend on an old browser. Each exception needs a business justification, a compensating measure such as network restriction or isolated browsing, a named approver and an expiry date. Set the window in your written policy, and note that the assessment specification examines whether the process is followed. Done means an approved policy and an exception register exist, and each exception has a reviewed record. The register is the artifact an assessor will sample most closely.
Measure unsupported share, false positives and false negatives
Run the measurement on a fixed schedule and record three values: the percentage of unsupported browser and email client software in use, the rate of false positives where a product is flagged in error, and the rate of false negatives where an unsupported product is missed. Sample a set of devices by hand each cycle to estimate both error rates, and record how the sample was chosen. Track the results over time to show the trend. Done means a dated metrics report exists for each cycle, with the method, sample and reviewer. Ask your assessor which sampling approach they will accept before you set the cycle length.

Evidence that satisfies Safeguard 9.1 and how to keep it current

Safeguard 9.1 is measured through software inventory data, support status, exception records and enforcement settings. The six artifacts below connect those sources so an assessor can trace each percentage and rate back to a dated record. Confirm the refresh intervals and sign-off roles against your own audit calendar and the assessor's requirements.

Browser and email client inventory export

A dated export of every browser and email client found on enterprise endpoints, listing product, exact version, install path, device owner and last-seen date. It is the population the Safeguard 9.1 measures divide by, so an assessor will check whether it covers managed laptops, servers, virtual desktops and bring-your-own-device enrollments. Pull it from the software inventory that Safeguard 2.1 requires, and confirm that the inventory tool reports installed versions rather than only package names. Refresh it at least monthly between audits, and have the IT asset owner sign off on coverage.

Vendor support baseline record

A signed, dated register that names each approved browser and email client, its vendor-supplied latest version and the vendor's published end-of-support date. Safeguard 9.1 requires only fully supported software at the latest vendor version, so this record defines what counts as unsupported for every later calculation. Record the source you used for each vendor date, and note when the baseline was last reviewed. Review it whenever a vendor announces a release or end-of-support change, and have the security architect and the application owner approve each change.

Unsupported software report with trend data

A report that calculates the percentage of unsupported web browser and email client software in use, which is the first of the three metrics in the assessment specification. Keep each month's result alongside the population size, the count of unsupported installations and the list of affected devices, so the trend shows movement rather than a single snapshot. An assessor will test whether the numerator and denominator match the inventory export for the same date. Generate it monthly, and have the control owner review the trend before it goes to management.

Validation records for false positive and false negative rates

Samples that show how often the inventory flagged a compliant browser as unsupported (false positives) and how often it missed an unsupported one (false negatives). The assessment specification uses these rates as metrics, so they must be measured, not assumed. Build the sample by comparing the inventory against a manual check of a defined set of endpoints, and document the method, sample size and reviewer for each run. Repeat the validation on a schedule you can defend, and have the independent reviewer on the security team sign off the results.

Remediation tickets and exception approvals

Tickets that track each unsupported installation from detection to upgrade or removal, along with exception records for any software that cannot be upgraded yet. Each exception needs a named business owner, a documented compensating control, a justification and a firm end date, after which the software must be removed or the exception renewed through approval. Assessors look for overdue items and exceptions without an end date, which are the most common gaps. Review open tickets weekly and expired exceptions monthly, with the risk owner signing off on every renewal.

Configuration enforcing the approved baseline

The settings and policies that stop unsupported or unapproved browsers and email clients from running, such as application allowlisting, managed update policies and removal rules applied through endpoint management. Export the active configuration and the change history, because an assessor will compare what the policy says with what devices actually enforce. Confirm that the enforcement mechanism supports version-based rules, since a control that only checks presence will not catch old versions. Export the configuration at each quarterly review, and have the endpoint platform owner sign off on any change to the enforcement rules.

What meeting Safeguard 9.1 costs in money and effort

This table lists the cost components of meeting Safeguard 9.1, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no price is published for any component and the largest variable is the state of your existing software inventory.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Tooling or licenses for software inventory and endpoint management	Software vendor or your existing platform team	Recurring (subscription or support)	Existing endpoint management may already collect installed software, so confirm coverage before buying. Open-source options such as GLPI and Wazuh can remove license spend, but still need hosting and administration time.
Engineering time to build the browser and mail client baseline	Internal platform team or an implementation partner under a written scope	One-time	Number of browser and mail client variants, and whether approved versions and vendor support end dates are already documented.
Engineering time to build the reporting for the three metrics	Internal engineers or an implementation partner	One-time, with periodic changes	Whether the inventory can report unsupported versions directly or needs custom queries and dashboards.
Recurring upkeep of the software inventory and metrics	Your operations or security team	Recurring	Fleet size, rate of device churn, and how often vendors change browser and mail client release schedules.
Remediation effort for unsupported installs	Endpoint, desktop or IT support staff	Recurring, varies by period	Device ownership model (corporate or bring-your-own), whether updates are pushed centrally, and how many users run locked-down versions.
Exceptions handling and documented risk acceptance	Security, IT leadership and the business owner of the exception	Recurring	Number of business applications that depend on an older browser or mail client, and whether exceptions have an expiry and review date.
External validation or review of the inventory and metrics	Independent assessor or consultant, under a written scope	Recurring at each assessment cycle	Scope of systems in the assessment, quality of the evidence you already keep, and the assessor's sampling approach.
Auditor sampling and evidence requests	Your compliance and IT staff, and the external auditor who is paid by the client	Recurring at each audit	Number of samples the auditor selects, how easily evidence can be exported from the inventory, and whether exports are reproducible.
Quote request items	Vendors, implementation partners and assessors	Both	Ask each bidder to itemize licenses, build hours, upkeep hours, remediation support and any assessor fees separately, and to state assumptions about fleet size and variant count.

How GLPI and Wazuh produce the inventory and support evidence for Safeguard 9.1

Safeguard 9.1 is measured against software that is actually installed and whether each version is still vendor-supported. GLPI and Wazuh can each record installed software, and combined they can show where unsupported browsers and email clients run, but neither decides support status on its own.

GLPI Assets module

The Assets module in GLPI (GPL-3.0-or-later) holds computers and the software installed on them, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. Use it as the system of record for which browser and email client versions are deployed on each device, which is the software inventory that Safeguard 2.1 calls for and that the assessment specification treats as a prerequisite for measuring Safeguard 9.1. Confirm with the GLPI documentation how it reports support status against vendor end-of-support dates, since a version number alone does not show whether it is still supported.

Wazuh Syscollector inventory

The Wazuh Syscollector module (GPL-2.0-only) collects installed software, operating system details and other endpoint data, then stores it in the Wazuh indexer for inventory views and dashboard reports. For Safeguard 9.1, this gives a continuously refreshed list of browser and email client builds across endpoints, which makes it easier to spot versions that drift out of the approved baseline. Wazuh does not know which vendor versions are still supported, so confirm that version and support status come from a separate, maintained source before reporting a percentage of unsupported software.

Combining GLPI and Wazuh

Use GLPI as the asset register and Wazuh as the endpoint-level check, then reconcile the two. Differences between the lists show devices missing from one source, which is a finding in itself, and both sources should be compared on the same browser and email client names and versions. Illustrative example: if GLPI lists a device that Wazuh has not reported for several weeks, the gap points to an agent problem to resolve before the metric is trusted. Record the reconciliation as evidence of how the inventory is kept complete.

Support baseline the organization supplies

Neither tool contains the authoritative list of which browser and email client versions the enterprise permits. The organization must maintain a baseline that records each approved product, its latest vendor-provided version and the vendor's published support end dates, with an owner and a review date. Without that baseline, the inventory cannot show whether software is fully supported, and the false positive and false negative rates in the assessment specification cannot be calculated meaningfully.

Remediation process the organization supplies

Finding an unsupported browser or email client is only useful if it leads to a documented action. The organization needs a process that sets a remediation deadline, assigns an owner, defines when an exception may be approved and how that exception is reviewed. Keep the tickets, approvals and closure records, because an assessor will look for evidence that identified gaps were acted on, not only that they were detected.

Who does what: the organization, an implementation partner and the auditor

Your organization owns Safeguard 9.1. It decides which browsers and email clients are approved, who maintains that list, how fast unsupported versions must be retired, and who signs off on exceptions. Those decisions are management decisions, and no partner or auditor can make them for you. The Safeguard asks that only fully supported browsers and email clients run in the enterprise, at the latest version the vendor supplies, so the baseline you define needs to name the products, versions and support end dates you accept.

Support baseline: Define the approved browsers and email clients, the minimum acceptable version, and the source you use to confirm vendor support status.
Exception approval: Set who may approve a time-limited exception to the baseline, what compensating controls apply, and when the exception expires.
Remediation ownership: Assign owners for upgrading or removing unsupported software, with deadlines tracked in your ticketing or change process.
Measurement decisions: Decide how you will report the metrics in the assessment specification, including how false positives and false negatives are reviewed.
Accountability: Keep the organization's name on the control, its evidence and any residual risk accepted by management.

Check that your written policy names an accountable owner for this Safeguard and that the owner can produce current inventory data on request.

Where organizations fall short on Safeguard 9.1 and how to close each gap

Most gaps under Safeguard 9.1 come from measurement, not from missing software. The assessment specification expects a complete inventory, a recorded support baseline, tracked exceptions and a tested view of errors in the metrics. Each card below names one gap, why it weakens the evidence and what to check before an assessor asks.

Inventory covers managed laptops only

Browsers and email clients on virtual desktops, shared kiosks, servers used for remote sessions and bring-your-own devices often never reach the software list. Safeguard 9.1 is measured against the software that actually runs, so an inventory that only reflects managed laptops understates the population. Check that the inventory source covers every device class in scope, and compare its count against directory or endpoint management records. Open-source inventory tools such as GLPI and Wazuh can collect installed software from endpoints, but coverage still depends on which hosts the agents reach.

No recorded vendor support baseline

When the team decides from memory whether a browser or mail client is supported, the decision cannot be repeated or audited. Record, for each product in scope, the vendor's current supported version, its release date and the date it goes out of support, and review that record on a fixed schedule. The baseline is the reference point that turns a version number in the inventory into a pass or fail result under Safeguard 9.1.

Unsupported versions on virtual and shared systems

Virtual desktop images, golden images and kiosk builds are often frozen for long periods and then cloned, so an old browser can run for months without anyone noticing. Inspect the base images and the running sessions, not only the endpoint agent data. Ask who owns each image, how often it is rebuilt and whether a browser update is part of the rebuild process. Flag any image whose browser is outside vendor support, even if no user sits at it today.

Exceptions without an owner or end date

Some business applications require an older browser or mail client, and those exceptions tend to become permanent. Each exception should name the application, the accountable owner, the compensating controls such as isolation or restricted network access, and a retirement date. Review open exceptions at a set interval and close any that have passed their date. An assessor will ask for this register, and an exception with no owner is hard to defend as a managed risk.

Metrics without a false negative test

Reporting the percentage of unsupported software tells you little if the inventory misses some of it. The assessment specification for Safeguard 9.1 includes measures for false positives and false negatives, so the team needs a method to test for both. Pick a sample of endpoints, check their actual browser and client versions by hand or with a separate scan, and compare the results with the inventory. Record the sample size, the method and the mismatches, and keep the results with the metric.

Extensions and bundled engines left unlisted

Browser extensions, email add-ons and applications that embed their own browser engine can run code outside the software list, even when the main browser is current. Include extensions and embedded engines in the inventory, and record each one's source and support status. Applications with bundled engines should be checked for the engine version, since updating the parent application may not update the engine. Confirm whether your inventory tool reports extensions before you rely on it for this check.

Questions buyers ask about Safeguard 9.1 cost, effort and outside help

How much effort does Safeguard 9.1 take and what drives it?

The effort depends mainly on how many browsers and email clients are in use, how well the software inventory is maintained, and how much unsupported software has to be removed or upgraded. Safeguard 9.1 is measured against the software inventory in Safeguard 2.1, which the CIS Controls Assessment Specification lists as a prerequisite because it typically produces the data the measurement needs. If that inventory is current, the main work is checking each browser and email client version against the vendor's support status and the latest vendor-provided release. If it is not current, the first effort is building it. Other drivers include the number of device groups, how many applications need compatibility testing before an upgrade, and whether legacy line-of-business applications depend on an unsupported browser. Ask any partner to break the estimate into inventory work, support-status checks, upgrade or removal work, and measurement reporting.

How long does a first Safeguard 9.1 measurement cycle take?

No fixed duration applies across organizations, so the timeline depends on the state of your inventory and the size of your estate. The first cycle usually takes longer than later cycles because it includes building or validating the software inventory, agreeing which browsers and email clients are approved, and clearing unsupported versions. Schedule risk comes from change windows, application compatibility testing, and users who must be moved to a new version. Ask for a written schedule with milestones for inventory validation, baseline agreement, remediation and the first measurement report, and confirm which steps depend on your change board or on business owners who must sign off.

What does the organization need to provide for this work?

Three things need to be in place before the work starts. The first is read access to the software inventory, or the means to produce one from your endpoint management or inventory tools. The second is a named owner for the supported browser and email client baseline, who decides which products and versions are approved and who keeps that list current. The third is remediation authority: someone who can require users or teams to upgrade or remove software, and who can approve exceptions with a documented end date. Without the third, the measurement will show the gap but nothing will close it. Confirm these three roles in the statement of work, with named individuals rather than departments.

Can an in-house team implement Safeguard 9.1 without an outside partner?

Yes, many organizations do this in house, and the Safeguard is one of the more direct IG1 controls to operate. The work is mostly inventory, version checking and change management, which existing IT and endpoint teams already perform. Outside help is more useful when the inventory is incomplete, when the platform must be built or integrated, or when the team lacks capacity to produce repeatable evidence. Whatever the staffing model, the organization owns the control. Decide who will run each measurement cycle, who reviews the results, and where the evidence will be kept before choosing between in-house delivery and a partner.

What should a fixed-scope quote for Safeguard 9.1 include?

A fixed-scope quote should be built from a written scope, and it should state what is in and out. Ask for the list of systems and endpoint populations covered, the inventory sources that will be used, and the browser and email client products in scope. Ask which deliverables are included, such as an approved baseline document, a support-status report, a remediation plan, configuration or deployment work, and the measurement report that feeds the assessment. Confirm the start and end conditions, the assumptions the timeline depends on, what customer responsibilities apply, how changes to scope are priced, and whether ongoing measurement is a separate retainer. DeployOpen does not publish a price list, and a quote follows from the written scope.

Can a partner issue the Safeguard 9.1 assessment result?

No. A partner can prepare systems, inventories, baselines and evidence, but only an independent assessor or auditor can issue an assessment result, report or certification. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. The CIS Controls Assessment Specification defines the measures and metrics used to verify Safeguard 9.1, but it describes what to measure, not how to run an independent review. If you need a third-party view, agree with your assessor early which evidence they will accept and how they will sample it.

Can self-hosted open-source tools replace licensed software for this control?

They can supply much of the evidence, but whether they replace licensed tooling depends on your environment. GLPI's Assets module can manage computers, software and other assets, with entries made manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. Wazuh's Syscollector module collects installed software and operating system details from each endpoint and stores them for inventory views and reports. Confirm that each tool captures the software and version data you need for every browser and email client, on every platform in scope, and that its output can be exported as evidence. Where gaps remain, licensed endpoint management may still be needed. Check Wazuh and GLPI licensing terms against your own use.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems and evidence behind Safeguard 9.1, which limits browsers and email clients to fully supported versions. The organization owns the control and its risk decisions, and an independent auditor or assessor is the only party that issues a report or certificate.

How we scope

We confirm which browsers, email clients and operating systems are in the enterprise and which are managed by the client's own tooling.
The written scope names the endpoint populations, the software inventory source and the vendor support dates we will check against.
We agree in writing which measures from the assessment specification will be evidenced, and which remain with the client's own process.

How we build

We deploy or configure inventory collection in the client's own environment, so unsupported browser and email client versions appear in reports.
We set up the software inventory prerequisite for Safeguard 2.1 so Safeguard 9.1 measurements draw on a consistent source of data.
We test the detection logic against known supported and unsupported versions, and record false positive and false negative rates for review.

How we hand over

We document the inventory queries, report definitions and the measure calculations used for the percentage of unsupported software in use.
We provide an evidence pack with dated inventory exports, the approved supported-version list and the remediation tickets raised for exceptions.
We walk the client's team through the process so they can rerun the reports and explain the results to an assessor themselves.

How we support

Ongoing support, upgrades and continuous checks of the inventory are available as a retainer after the fixed-scope work is complete.
We review changes to browser and email client support lifecycles and update the supported-version list and detection rules accordingly.
Before an assessment, we can help the client confirm that its evidence matches the written scope, while the auditor decides what is accepted.