Why does an accessibility scanner need a security review at all?

Because a modern accessibility platform is not a linter. To find the failures that matter it has to load your pages in a real browser, and to reach the parts of your product where real users get stuck it has to log in with a credential you gave it. Once it is authenticated it is rendering pages that contain customer records, and most platforms store a screenshot and a DOM snapshot of each finding as evidence. That makes the vendor a processor holding your customers' personal data on their infrastructure, which is exactly the shape a vendor security review exists to catch. A tool that only crawls your marketing site is a much smaller review, and saying so early shortens it.

What is the single question that disqualifies the most vendors?

Ask what is stored with each finding and for how long. The useful answer names the artefacts — screenshot, DOM snapshot, HTTP response body, request headers — says where they live, says whether they can be disabled per scan profile, and gives a retention window you can set. The answer that ends an evaluation is a vague assurance that everything is encrypted. Encryption at rest is table stakes and does not address the actual risk, which is that a screenshot of an authenticated page is a copy of a customer record sitting in a third-party system for as long as the contract runs.

Should we give an accessibility vendor a login to our production app?

Give it a dedicated service account with the narrowest role that can still reach the screens under test, seeded with synthetic records rather than real customers, and scoped to a non-production environment if one exists that genuinely mirrors the real markup. Never a shared human account and never an administrator. Make sure the account can be rotated without a support ticket, that the scan cannot submit destructive forms — ask specifically how it handles a delete button, because some crawlers click everything — and that it is covered by whatever access review your organisation runs on other third-party credentials.

Does an accessibility vendor need a DPA?

If it authenticates into a product that holds personal data, yes, and it needs a subprocessor list too. The subprocessor list is the part people skip and it matters here more than in most categories: accessibility platforms commonly run their browser fleet on a third-party grid, store evidence in another provider's object storage, and increasingly send page content or screenshots to a hosted model for alt-text suggestions or issue summaries. Each of those is a place your authenticated page content travels to. Ask for the list in writing and ask specifically whether any AI feature transmits page content off their infrastructure, and whether it can be turned off.

Is SOC 2 enough to clear the review?

It is the entry ticket and it is not the answer. Ask for the Type II report under NDA rather than the badge on the website, then read two things: the scope section, to see whether the product you are buying is actually covered or whether the report covers a different platform the company also sells, and the exceptions. A SOC 2 with a narrow scope is common in this category because several accessibility vendors grew by acquisition and run more than one scanning stack. A vendor that will only ever show you a logo, or whose report predates the product you are evaluating, has told you something.

What about overlay vendors specifically?

An overlay is a different and larger risk than a scanner, because it is third-party JavaScript executing on every page of your site with full DOM access, inside your users' sessions. That puts it in the same review category as a tag manager or a session recorder, not in the category of a reporting tool: it can read form fields, it is a supply-chain dependency, and an outage or a compromise at the vendor is an incident on your site. If your organisation has a content security policy, an overlay usually requires loosening it, which is a conversation worth having before the contract rather than during deployment.

The Security Review an Accessibility Vendor Has to Pass in 2026

The Review Is Larger Than Teams Expect, for One Structural Reason

An accessibility checker sounds like a reporting tool, and if it only ever crawls a public marketing site, it nearly is one. The moment the evaluation includes the authenticated product — which is where the failures that produce complaints actually live, because nobody files a demand letter about a pricing page — the category changes. The vendor now holds a credential into your application, renders screens containing real records, and in most products keeps a screenshot and a DOM snapshot of every finding so a developer can see what broke.

That is a processor holding customer personal data, and it will be reviewed like one. The practical consequence is scheduling: if you discover this at contract stage, you have added six to twelve weeks to a purchase you told your stakeholders would close this quarter. The fix is not to avoid authenticated scanning — it is the most valuable thing the platform does — but to start the security conversation in parallel with the trial rather than after it.

Question One: How Does It Authenticate, and as Whom

Vendors differ enormously here and the difference is rarely on the pricing page. Some support a scripted login with a stored credential, some support session-cookie injection, some support header-based authentication, some support single sign-on flows and some simply cannot get past a login form with a second factor. A platform that cannot authenticate against your stack is not a cheaper option; it is a tool that measures the twelve per cent of your surface nobody sues over.

Which mechanisms are supported — scripted form login, cookie or header injection, OIDC, and whether a second factor can be handled with a bypass code scoped to one service account.
What the crawler clicks. Ask directly how it treats destructive controls. A crawler that submits every form it finds inside an authenticated account is a data-integrity incident waiting for a Friday.
Egress addresses. If your product sits behind a WAF or an allowlist, you need a stable source range, and "it varies" means someone on your side will be whitelisting a cloud region.
Credential handling — where the secret is stored, who at the vendor can read it, and whether you can rotate it yourself without opening a ticket.

Question Two: What Is Kept, Where, and for How Long

Evidence is the feature and the liability at the same time. A finding with a screenshot and the failing markup attached is the difference between a ticket a developer can close and a line item nobody actions — and it is also a copy of an authenticated page living in someone else's object storage for the length of your contract.

The answer you want is specific and boring: these artefacts, in this region, for this many days, redactable by selector, disableable per scan profile, deletable on request with a stated turnaround. The answer that should worry you is a reassurance about encryption. Everyone encrypts at rest. The question is what exists to be encrypted, and whether your legal team knows it exists. Ask whether evidence capture can be switched off for authenticated profiles specifically, because that single toggle often converts a twelve-week review into a three-week one.

Data residency belongs in the same conversation. If you sell into the EU, the browser fleet and the evidence store both need to be in scope, and they are frequently in different places from the application database the sales engineer will tell you about.

The AI Features Are a Subprocessor Question Now

Nearly every platform in this category shipped AI assistance in the last two years: suggested alt text, plain-language summaries of a violation, generated remediation code. Useful features, and each one is a path by which page content — sometimes a full DOM snapshot of an authenticated screen — leaves the vendor's infrastructure for a model provider's.

Three questions settle it. Which features transmit page content off-platform; which model provider receives it and under what retention and training terms; and can the feature be disabled tenant-wide rather than per user. If a vendor cannot answer the first question without checking, that is itself the finding — it means the answer is not written down anywhere your auditor could rely on either.

The Rest of the Questionnaire, Compressed

SOC 2 Type II under NDA, read for scope and exceptions. Check the report covers the product you are buying — acquisitive vendors in this space often run more than one scanning platform under one brand.
Subprocessor list in writing, including the browser grid, the evidence store and any model provider.
SSO and SCIM, and whether SSO is gated behind an enterprise tier. It usually is; price it now, not at renewal.
Role granularity — whether a developer who needs to see findings necessarily also sees stored screenshots of authenticated pages.
Audit log export, so an access review can actually be evidenced rather than asserted.
Breach notification window and the incident contact route, written into the agreement rather than the trust page.
Deletion on termination — a stated turnaround for destroying evidence, and confirmation that backups are covered.
Penetration testing cadence and whether a summary letter is available to customers.

Sequence It So the Review Runs Beside the Trial

The expensive failure mode is serial: three vendors demo, one wins on features, and only then does the questionnaire go out — to discover that the winner cannot authenticate against your identity provider, or stores evidence in a region your DPA does not cover. You have now spent a quarter and have to restart with the runner-up.

Send the eight lines above to every vendor in week one, before any deep evaluation. They are cheap to answer for a vendor that has the answers, and the ones that do not will take three weeks to reply — which is the signal. Then run the trial against whoever survives, and let your security team read the SOC 2 while the scan is running rather than after the decision is made.

If You Are Not Scanning Authenticated Pages at All

Say so explicitly, in writing, and the review shrinks to almost nothing. A tool that crawls only public marketing URLs processes no personal data on your behalf and the questionnaire becomes a formality. This is a legitimate and cheap first step, and it is the right one if your risk is concentrated in a public storefront. Just be honest about the trade: you are buying coverage of the pages that are easiest to fix and least likely to generate a complaint, and the day you extend into the product, the full review arrives with it.

Questions Procurement Teams Ask

How long does a security review of an accessibility vendor usually take?

For a public-site-only scanner, days. For anything that authenticates into a product holding personal data, plan six to twelve weeks from questionnaire to signature, longer if a DPA needs negotiating or if the vendor's subprocessor list contains a model provider your legal team has not previously approved. The variable that moves this most is not the vendor's security posture but whether you started the review in parallel with the trial or after it.

The vendor says they are SOC 2 compliant. Can we stop there?

No, and not because the claim is dishonest. SOC 2 is scoped by the company being audited, so the meaningful information is which systems the report covers and what exceptions the auditor recorded — neither of which is on the trust badge. Ask for the Type II report under NDA, check the in-scope system description names the product you are buying, and read the exceptions section. If the report is more than a year old or covers a platform the company acquired separately, keep asking.

Can we avoid giving the scanner a login by testing a staging environment?

Sometimes, and it is worth exploring, but verify that staging actually mirrors the markup you care about. Staging environments frequently run with feature flags off, seeded data that never exercises the empty-state and error paths where the worst failures live, and a different CDN or consent banner. If staging is a genuine mirror, you get most of the coverage with a fraction of the review. If it is a stale branch with ten fake users, you are measuring a site that does not exist.

Our accessibility budget sits with marketing, not IT. Does that change anything?

It changes who finds out about the review, and when. Accessibility tooling is bought by marketing, design or legal far more often than by engineering, and those buyers are the ones most likely to reach contract stage without having spoken to InfoSec. The cheapest thing a non-technical buyer can do is forward the eight questions above to the vendor in week one and copy their security contact. It costs nothing and it converts a surprise into a schedule.

What does an overlay change about the review?

It escalates it. An overlay is third-party script running in every visitor's session with full DOM access, which is a supply-chain and privacy question rather than a reporting one — closer to a session recorder than to a scanner. Expect questions about content security policy, script integrity, what the vendor logs about your visitors, and what happens to your site when their CDN has a bad day. Several organisations that permit scanning vendors freely will not permit an overlay at all.

Should the security questionnaire be part of the RFP or separate?

Part of it, and near the front. Putting the disqualifying questions in the first document you send means the vendors that cannot pass remove themselves before anyone on your side builds a preference. It also produces written answers you can hold a vendor to later, which a demo conversation does not. The failure this avoids is the common one: choosing on features, then discovering the winner is unbuyable.

Know What You Are Buying Before the Review Starts

A security review is expensive to run on the wrong finalist. Before you spend one, get a neutral reading of your own public pages so you know how much of your risk is actually behind a login — and therefore how big a review you are signing up for.

Then judge the shortlist on the four structural lines that a questionnaire cannot answer: can it reach your authenticated pages, can a finding become a ticket, does the pricing unit match how your site grows, and will the output convince someone outside your team.