Evidence for the technology decisions already on your desk.

NIST finalized Special Publication 1326, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, on July 8, 2026. The publication gives technology buyers a practical starting point for investigating ICT suppliers before acquisition decisions and for revisiting supplier risk when conditions change. NIST defines due diligence as researching pertinent available information about a supplier or product so that acquisition or continued-use decisions can be informed. For public-sector buyers, the important shift is procedural: supplier security should not begin and end with a questionnaire. The procurement record should show what was examined, what was learned, what remains uncertain, who accepted the risk, and which changes force another review.

SP 1326 gives buyers five due-diligence lenses

The final guide organizes supplier due diligence around five components: Foreign Ownership, Control, or Influence (FOCI); Provenance; Resilience; Foundational Cyber Practices; and Supply Chain Tiers. Those categories are useful because they prevent a vendor review from collapsing into a generic list of cybersecurity controls. A supplier can have reasonable internal security practices and still create material risk through opaque ownership, unknown component origins, fragile operational dependencies, or concentrated upstream suppliers. Conversely, one adverse signal should not automatically be treated as a disqualifier without understanding context, exposure, mitigations, and the importance of the service.

FOCI asks the buyer to understand who owns, controls, or can materially influence the supplier. Provenance focuses attention on the origin and custody of products, components, software, and relevant development or manufacturing paths. Resilience concerns the supplier's ability to withstand disruption and continue or restore delivery. Foundational Cyber Practices address the security behaviors and controls that should be visible at a basic level. Supply Chain Tiers force the review past the contracting entity to the dependencies behind it. Together, the five lenses create a more complete picture than a single security score.

NIST describes SP 1326 as an implementation-ready quick-start approach based on SP 800-161 Revision 1, not a replacement for the broader C-SCRM guidance. That distinction matters in procurement. A quick-start guide can establish a defensible minimum review pattern, while an agency's own risk-management framework, acquisition authority, system categorization, data sensitivity, mission dependencies, contractual obligations, and legal requirements determine how deep the investigation must go.

Turn the five lenses into evidence requests, not yes-or-no questions

The easiest way to weaken supplier due diligence is to ask questions that vendors can answer with unsupported assurances. Instead of asking whether a supplier has a resilient supply chain, ask what evidence demonstrates resilience for the specific product or service being acquired. That evidence might include continuity architecture, recovery objectives, dependency maps, geographic concentration, alternate suppliers, incident history, tested recovery procedures, service-level commitments, or a description of known single points of failure. The appropriate evidence varies by purchase, but the response should be reviewable.

The same approach works for provenance. A buyer evaluating software or a cloud-delivered platform may ask how the supplier tracks component origin, build provenance, third-party libraries, deployment artifacts, and material subcontracted development. Hardware acquisitions may require a different evidence set. The objective is not to demand every possible artifact from every vendor. It is to identify the provenance facts that could materially change the organization's decision and then obtain enough evidence to evaluate those facts.

FOCI and supply-chain-tier research often combine supplier-provided information with public records and other permitted sources. Buyers should distinguish verified facts from inferences and unresolved questions. A procurement file is stronger when it says, for example, that an ownership relationship was confirmed through a named public record and that a second-tier dependency remains unverified, rather than turning both observations into one opaque red-yellow-green score. This preserves the evidence trail for later reviewers.

Use basic due diligence broadly and deepen it when risk warrants

NIST's final publication is designed to help acquirers conduct a reasonable level of research even when resources are limited. That is valuable for public organizations because a mature C-SCRM program cannot reserve all supplier scrutiny for a handful of strategic contracts. The operating model should be scalable: establish a repeatable baseline review for ICT suppliers, then increase the depth when the product, access, data, mission role, concentration, or threat exposure makes the consequence of supplier failure materially higher.

A practical intake can therefore begin before the formal security questionnaire. Identify what is being purchased, what systems or information it will touch, whether it will receive privileged access, whether it becomes part of a public or internal critical workflow, whether the agency can operate without it, how hard it would be to replace, and which subcontractors or upstream platforms are essential to delivery. Those answers help determine which of the five SP 1326 components deserve enhanced investigation.

This is also where supplier due diligence connects to the rest of procurement rather than living in a separate cyber review. The same evidence can inform technical evaluation, continuity planning, contract terms, implementation sequencing, data-exit requirements, incident notification, insurance review, records obligations, and executive risk acceptance. Zeph Tech's technology vendor security questionnaire can capture control evidence, while the continuity and exit-readiness checklist helps evaluate what happens when the supplier or relationship fails.

Record the decision, not just the research

A pile of vendor documents is not a due-diligence decision. For each material supplier, preserve a concise decision record that identifies the supplier and product in scope, evidence sources reviewed, significant findings by due-diligence component, unresolved uncertainties, applicable risk owners, mitigations or contract conditions, the final decision, and the date or event that triggers another review. This makes the assessment auditable and reduces the chance that later staff have to reconstruct why a supplier was accepted.

Conditions are especially useful when the organization is willing to proceed despite an unresolved risk. A condition might require delivery of updated evidence before production access, completion of a remediation milestone, notice of a material ownership change, periodic disclosure of critical subcontractors, a tested export process, or executive approval before a dependency is moved to a new jurisdiction. The procurement team should avoid creating conditions that no one owns or monitors; every condition needs a responsible role and a way to verify closure.

The decision record should also avoid false precision. NIST's categories provide structure, but supplier risk rarely collapses honestly into a single universal number. If the organization uses scoring, the underlying observations and decision logic should remain visible. A high aggregate score should not erase a mandatory legal, security, accessibility, records, or mission requirement, and a low score should not substitute for understanding the actual risk pathway.

Supplier due diligence must continue after award

The information used to approve a supplier can change. Ownership changes, acquisitions, new subcontractors, data-center moves, product architecture changes, security incidents, financial deterioration, end-of-life notices, sanctions or export-control developments, and service concentration can all alter the original risk picture. A useful C-SCRM process therefore defines monitoring triggers at the time of the initial decision instead of assuming the assessment remains valid for the life of the contract.

Not every change requires a complete reassessment. A trigger-based model is more efficient. For example, a material ownership change may reopen the FOCI review; a new critical hosting provider may reopen supply-chain tiers and resilience; a major product rewrite may require renewed provenance and foundational cyber-practice evidence; repeated outages may justify a deeper resilience review. The key is to connect the trigger to the risk lens instead of performing a ceremonial annual questionnaire with no relationship to what changed.

Contract language can support that monitoring model. Depending on authority and risk, buyers may require notice of material ownership or control changes, critical subcontractor changes, significant security incidents, material architecture changes, or service discontinuation. Data portability, records retention, transition assistance, and evidence access after termination can reduce the impact of supplier failure. These are procurement and operational controls, not substitutes for the underlying security assessment.

A public-sector supplier review can be concise without being superficial

Teams do not need a massive bespoke process to begin applying SP 1326. Start with a short supplier dossier. Under FOCI, document ownership, controlling interests, relevant affiliates, and material influence signals. Under provenance, document the origin and custody facts that matter for the acquired product. Under resilience, identify critical dependencies and the supplier's ability to continue or restore service. Under foundational cyber practices, request evidence appropriate to the access and data involved. Under supply-chain tiers, identify upstream parties whose failure would materially affect delivery.

Then add the decision layer: what risk matters, how likely or consequential it appears given the available evidence, what is unknown, what mitigation exists, who owns the decision, and what condition or future event requires review. This is where the process becomes useful to executives and auditors. The result is not merely a completed cybersecurity form; it is an evidence-backed explanation of why the organization believes the supplier is acceptable for a defined use.

For organizations building or refreshing this process, the public-sector technology procurement toolkit provides a broader acquisition path, and the technology evaluation brief builder can turn workflow, information-boundary, dependency, and decision-horizon inputs into buyer questions. Those tools should be adapted to the organization's authority and procurement rules rather than treated as a substitute for legal, acquisition, or security review.

Questions for the next supplier decision

• Who owns or materially controls the supplier, and which ownership or influence facts could change our risk decision?
• What do we know about the origin and custody of the product, software, components, or development path that matter to this purchase?
• Which disruptions could prevent the supplier from delivering the service, and what tested recovery or alternate paths exist?
• What evidence demonstrates foundational cybersecurity practices appropriate to the access, data, and mission role we are granting?
• Which subcontractors, cloud providers, manufacturers, developers, or other upstream tiers are essential to delivery?
• Which findings are verified facts, which are supplier assertions, and which remain unresolved?
• Who owns each mitigation or contract condition, and how will completion be verified?
• Which ownership, architecture, dependency, incident, financial, or product change forces a new review?

NIST SP 1326 gives buyers a practical vocabulary for asking better supplier questions. Its value is not in creating another compliance checklist. The stronger use is to make supplier decisions evidence-driven, explainable, and refreshable: investigate the five risk lenses, preserve what was learned, record uncertainty and accountability, and define the events that cause the organization to look again.

Two major U.S. government accessibility timelines changed in 2026. The Department of Justice extended the ADA Title II web and mobile application compliance dates for state and local governments, and the Department of Health and Human Services extended parallel Section 504 dates for recipients of HHS financial assistance. The extensions are operationally important, but they are not a reason to stop accessibility work. Both rule sets continue to point covered organizations toward WCAG 2.1 Level AA, and both agencies continue to describe web and mobile accessibility as part of broader nondiscrimination obligations.

For technology leaders, procurement teams, web owners, and vendors, the practical task is to use the extra year to move from broad intent to an evidence-backed program: identify which rule applies, inventory the digital services in scope, classify exceptions carefully, test high-value user journeys, fix procurement language, and preserve evidence that accessibility is being designed and validated throughout the lifecycle. this analysis is an operational summary, not legal advice; organizations should confirm applicability and interpretations with counsel or their responsible compliance authority.

The 2026 extensions created two different timelines

The Department of Justice issued an interim final rule effective April 20, 2026 extending the ADA Title II web and mobile accessibility compliance dates adopted in 2024. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Public entities with fewer than 50,000 people, and special district governments, now have until April 26, 2028. DOJ's updated fact sheet and planning guidance reflect those revised dates.

HHS issued a separate interim final rule effective May 7, 2026 for recipients of HHS financial assistance covered by the Department's Section 504 rule. Recipients with 15 or more employees now have until May 11, 2027 to meet the web and mobile accessibility requirements. Recipients with fewer than 15 employees now have until May 10, 2028. HHS described the change as a one-year extension and said the technical standard remains WCAG 2.1 Level AA.

Those dates are easy to blur together because the rules address similar accessibility outcomes. They should not be treated as interchangeable. ADA Title II status depends on the nature and population of the public entity. HHS Section 504 status depends on receipt of HHS financial assistance and the employee threshold used in that rule. Some organizations may be affected by both regimes, while others may fall under only one. The first project-management step is therefore a documented applicability map rather than a generic deadline entered into a calendar.

The extension is schedule relief, not a reset of accessibility obligations

DOJ's Title II resources emphasize that state and local governments already have obligations to provide accessible services, programs, and activities. The 2024 web rule adds specific technical requirements for web content and mobile applications, but the one-year extension does not convert accessibility into an optional future project. DOJ's planning guidance still tells public entities to identify responsible people, learn the rule, determine the compliance date, inventory web content and mobile apps, assess current accessibility, prioritize remediation, examine vendor contracts, and create policies.

HHS makes a similar distinction. Its 2026 announcement says the extension does not impose new obligations and gives recipients additional time to meet the specific technical standard. HHS also reminds recipients of continuing legal obligations to ensure programs and activities are accessible to people with disabilities. That matters for operational planning: a team should not interpret a 2027 or 2028 technical-conformance date as permission to leave a known barrier in a critical service untouched for another year.

A defensible roadmap separates immediate access problems from the full conformance program. High-consequence user journeys such as applying for benefits, accessing health information, submitting public forms, paying fees, requesting records, scheduling services, reviewing notices, or using authentication should receive priority based on user impact and service criticality. Lower-risk legacy content can then be handled through a documented inventory and remediation schedule, including evaluation of any rule-specific exceptions.

WCAG 2.1 Level AA is the common technical center of gravity

Both the DOJ Title II rule and the HHS Section 504 web and mobile provisions use WCAG 2.1 Level AA as the core technical standard. WCAG 2.1 includes testable criteria covering keyboard access, reflow, text spacing, non-text contrast, status messages, form semantics, orientation, input purpose, pointer interactions, and other accessibility needs. A program that treats accessibility as color contrast plus image alt text will miss a large portion of the actual interface and workflow risk.

Public-sector teams should also distinguish the legally referenced standard from newer design targets. WCAG 2.2 is available and may be valuable as an additional engineering target, but a procurement document should not casually substitute one standard for another without explaining the intended requirement. The strongest approach states the controlling legal or contractual baseline, any additional accessibility objective, the product and content scope, and the acceptance method.

This precision matters when buying software. A vendor may provide an Accessibility Conformance Report based on a particular VPAT edition, WCAG version, product release, or configuration. Buyers should compare the report to the rule and the actual deployed system rather than assuming that the word accessible is a complete answer. Zeph Tech's accessibility procurement checklist is designed to help teams request comparable evidence before award.

Inventory the service, not just the public website

DOJ's Title II rule reaches web content and mobile apps a public entity provides or makes available directly or through contractual, licensing, or other arrangements. HHS similarly addresses web content and mobile applications provided or made available by covered recipients. That means an accessibility inventory should include more than the main public website. Teams should look for SaaS portals, embedded payment services, appointment systems, document viewers, online forms, authentication flows, public records tools, kiosks where relevant, mobile applications, and third-party components that are part of the user journey.

The inventory should identify ownership and control. Record the service owner, vendor, contract, product version, authentication method, content owner, critical workflows, known accessibility evidence, current defects, and renewal or replacement date. This converts accessibility from a vague web-team responsibility into a governed technology portfolio. It also exposes procurement use: a system renewing six months before the compliance date deserves a different plan than one entering a five-year term now.

For document-heavy services, classify the document problem separately from application accessibility. PDFs, spreadsheets, presentations, word-processing documents, scanned images, and generated reports can create barriers even when the surrounding portal is accessible. Both DOJ and HHS rules include carefully bounded exceptions for certain content, but exceptions should be evaluated against the actual rule text and service context rather than used as a blanket reason to ignore archives or preexisting documents.

Turn the extra year into contract use

One of the highest-value uses of the extension is procurement cleanup. Every new solicitation, renewal, amendment, or major implementation creates an opportunity to require clearer accessibility evidence. Ask vendors for the current Accessibility Conformance Report for the exact product and version proposed, the test methods used, known defects affecting material workflows, remediation commitments, the accessibility product owner, and the event that triggers a new report or retest.

Acceptance language should define what happens when an accessibility defect is found. Identify which severity levels block release, who validates remediation, how retesting is documented, whether accessibility defects affect service-level or quality obligations, and how major interface changes are reviewed. For configurable systems, divide responsibility among the platform vendor, implementation partner, content authors, and agency. Accessible components can still produce inaccessible configured workflows, and accessible source content can still be rendered poorly by a product.

Public portal procurement deserves special attention because the public experience often combines search, filters, tables, forms, downloads, account functions, and records. Teams evaluating a portal should test representative workflows with keyboard-only navigation and appropriate assistive technology instead of accepting a home-page scan. The public-sector software RFP checklist and software evaluation scorecard can be used alongside accessibility evidence so the requirement affects the actual selection decision.

Build a 2026-to-2028 evidence trail

A good accessibility program should be able to show how it moved from discovery to measurable improvement. Start with a dated inventory and applicability decision. Preserve baseline testing results for critical workflows. Create remediation tickets tied to specific success criteria or user barriers. Record product versions and test environments. Keep vendor ACRs and clarification responses. Capture acceptance decisions and any documented exceptions or limitations. Repeat material tests after major releases rather than treating accessibility as a one-time certification exercise.

For large state and local governments and larger HHS-funded recipients, the revised 2027 dates make 2026 the year to establish the operating model. For smaller entities and special districts with 2028 dates, the longer runway should enable phased remediation instead of deferral. Early inventory also improves budgeting because it reveals whether the largest cost is content remediation, vendor replacement, application development, document conversion, testing capacity, or governance.

Organizations should also monitor the agencies' official rule pages for further changes. A static project plan is risky when regulatory materials can be amended, clarified, or supplemented. The safest practice is to store the authoritative source URL next to each compliance milestone and assign someone to re-verify it before major procurement, release, or audit decisions.

Questions to take into the next accessibility review

• Which entities, programs, websites, mobile apps, and vendor-operated services are in scope for us?
• Are we tracking the correct 2027 or 2028 deadline for each applicable rule?
• Which critical public or patient workflows have been manually tested, not merely scanned?
• Do current contracts require product-specific accessibility evidence and dated remediation commitments?
• Which documents or archived materials are being treated as exceptions, and is that classification defensible?
• What product, interface, or content change triggers retesting?
• Can leadership see a dated evidence trail from baseline findings through remediation and acceptance?

The 2026 extensions create breathing room, but the most valuable outcome is not a later deadline. It is the opportunity to replace reactive remediation with a repeatable accessibility operating model. Teams that use the additional year to improve inventory, procurement, testing, ownership, and evidence will be in a stronger position for compliance and will also deliver digital services that work better for the people who depend on them.

Reviewed September 2, 2026: Google introduced Gemini 3.7 Flash on August 13, 2026 as the next iteration in the Gemini 3 Flash family, following Gemini 3.6 Flash by roughly three weeks. Google positions 3.7 Flash as a stronger workhorse model for coding, agents, knowledge work, and multimodal tasks while retaining the Flash line's emphasis on throughput and cost. For enterprise buyers, however, the important question is not whether 3.7 posts higher vendor-reported benchmark numbers. It is whether those improvements survive contact with the organization's own documents, tools, data boundaries, latency targets, failure modes, and operating controls.

The release is also a useful example of why model procurement cannot rely on a one-time comparison table. A model that looked current in late July was superseded in mid-August. That does not make an earlier evaluation worthless, but it makes version pinning, revalidation triggers, and model-change governance essential. An enterprise evaluation should record the exact model, date, configuration, tool permissions, test set, acceptance criteria, and cost assumptions used to reach a decision.

What Google says improved in Gemini 3.7 Flash

Google DeepMind's August 2026 model card describes Gemini 3.7 Flash as an algorithmically improved successor with customizable thinking configurations that let developers trade among quality, cost, and latency. The model is listed with a one-million-token input context, up to 64,000 output tokens, function calling, search-as-a-tool, and computer-use support. Google lists availability across the Gemini API, Google AI Studio, Gemini Enterprise, Gemini Enterprise Agent Platform, and other Google surfaces.

Google's published benchmark table reports several material gains over Gemini 3.6 Flash. On FrontierCode 1.1, Google reports 43.6% for 3.7 versus 34.4% for 3.6. On DeepSWE v1.1, the reported result rises from 48.6% to 65.3%. Terminal-bench 2.1 moves from 78.0% to 85.8%, AutomationBench from 17.0% to 30.4%, GDP.pdf from 22.0% to 34.0%, and OSWorld-2.0 from 33.8% to 47.9%. Google also reports a smaller increase on its Artificial Analysis Intelligence Index comparison, from 52 to 56.

Those numbers are useful evidence of what Google chose to evaluate and where it claims progress, but they are vendor-reported benchmark results. They should not be presented as independent validation of performance in a buyer's environment. Benchmark methodology, prompting, tool access, run conditions, scoring, and task composition can differ materially from production use. A procurement team should use the published results to decide what to test more deeply, not to skip its own evaluation.

The biggest buyer signal is the pattern of change

The reported gains are concentrated in areas that matter to agentic and technical workflows: software engineering, terminal use, workflow automation, document comprehension, and computer interaction. That pattern should shape an enterprise test plan. If an organization is considering Gemini 3.7 for code assistance, tool-calling, document-heavy operations, or semi-autonomous workflow execution, its evaluation should reproduce the difficult parts of those workflows with the organization's actual permission boundaries and representative data.

For example, a coding evaluation should go beyond isolated code-generation prompts. Test repository-scale understanding, change planning, test repair, dependency awareness, rollback behavior, secrets handling, and whether the model asks for clarification when requirements are ambiguous. An agentic workflow test should measure not just task completion but tool-selection errors, repeated actions, privilege boundaries, recovery after partial failure, and whether the system can explain which external actions it took. A document workflow should include long, messy, contradictory, and structured files rather than only clean PDFs.

The comparison graphic on this page highlights a subset of Google's published 3.7-versus-3.6 results because the magnitude of improvement varies by task. A model can improve significantly on long-horizon engineering and automation while changing little on another task. The correct enterprise question is workload-specific: which failure modes became less common, which new capabilities matter, and which regressions or unchanged weaknesses remain operationally important?

Pricing needs a dated model, not a static screenshot

Google currently lists an introductory price of $0.75 per million input tokens and $3.75 per million output tokens for Gemini 3.7 Flash, with the model page noting that the introductory price expires December 31, 2026. Google states that beginning January 1, 2027, pricing will increase to $1.50 per million input tokens and $7.50 per million output tokens. That scheduled change belongs in any total-cost model created in 2026.

Token price alone is not total cost. Enterprise buyers should model prompt size, retrieved context, tool calls, retries, output length, cache behavior if applicable, orchestration overhead, human review time, failure remediation, and duplicated runs required for quality assurance. A model that is cheaper per token can still cost more per successful workflow if it requires more retries or produces more outputs that must be reviewed.

The safest procurement artifact is a dated scenario table rather than a generic statement that one model is cheaper. Include expected monthly request volume, median and high-percentile input/output sizes, projected tool calls, retry assumptions, expected human-review minutes, and at least one stress scenario. Recalculate when the provider changes price, model version, context behavior, rate limits, or terms that affect deployment.

Governance should assume the model will change again

The short interval between 3.6 and 3.7 is a governance signal. Organizations using hosted models should decide whether they pin a specific version, accept provider-managed upgrades, or operate a controlled promotion process between versions. Pinning can preserve tested behavior but may delay improvements or deprecation handling. Automatic upgrades reduce maintenance but can introduce untested behavioral changes. A staged promotion model requires more operational work but creates a repeatable place to run regression tests before changing production traffic.

A useful model-change control records the current production identifier, approved use cases, data classifications, connected tools, system prompts, safety controls, baseline evaluation results, known limitations, and rollback path. A new model version should trigger re-evaluation proportionate to the change. For a low-risk drafting assistant, a focused regression suite may be enough. For a system that can call tools, make external changes, access sensitive records, or influence consequential decisions, the revalidation threshold should be substantially higher.

Google's model card also contains safety and limitations information that belongs in the review. Model cards are not certifications, and a provider's safety evaluation cannot substitute for the customer's own risk analysis. The buyer should identify which misuse, hallucination, data-handling, tool-use, prompt-injection, access-control, and human-oversight risks matter for the proposed deployment, then test controls around those risks directly.

Build the evaluation around acceptance evidence

Start with representative workflows rather than a broad benchmark contest. Select twenty to fifty tasks that reflect real work, including difficult edge cases and known historical failures. Define success before running the test. Measure task completion, factual errors, unsupported claims, policy violations, latency, cost, tool-call accuracy, recovery from failed tools, and human-review effort. Preserve prompts, inputs, outputs, configuration, model identifier, and the scoring rubric so the same suite can be rerun after future model changes.

For knowledge work, include internal documents with conflicting dates, superseded policies, tables, long appendices, and facts that require the model to distinguish authoritative from outdated material. For coding, include repository context and test execution rather than isolated snippets. For agents, deliberately inject tool failures, unavailable resources, permission denials, untrusted content, and ambiguous instructions. For multimodal use, test the actual charts, images, PDFs, or video formats the organization expects to process.

Then separate provider claims from buyer findings in the decision record. Google's benchmark results belong under provider evidence. Your acceptance-test results are organization-specific evidence. Keeping those categories separate prevents marketing metrics from silently becoming procurement facts and makes the evaluation easier to defend later.

Zeph Tech's Evaluation Brief Builder can turn the intended workflow and evidence boundary into a first-pass test plan. Use the Software Evaluation Scorecard to compare task success, operational burden, governance, cost, and exit considerations consistently, and the Vendor Security Questionnaire when the deployment will introduce sensitive data, external tools, privileged actions, or new supplier dependencies.

Decision questions for enterprise buyers

• Which production workloads are expected to benefit from the specific capabilities Google reports improving?
• What exact model identifier and thinking configuration will be approved for production?
• Which vendor-reported benchmark claims are relevant enough to reproduce with internal tasks?
• How will the organization measure successful workflow completion, not merely plausible output?
• What permissions can the model or agent exercise, and what requires human confirmation?
• How will prompt injection, untrusted documents, tool failure, and repeated actions be tested?
• What is the cost per successful workflow under normal and stress assumptions?
• What happens when introductory pricing ends or a newer model supersedes 3.7?
• Which model changes trigger regression testing, security review, legal review, or renewed approval?

Gemini 3.7 Flash appears, based on Google's published evidence, to be a meaningful update to the Flash family in several coding, agentic, automation, and document-oriented evaluations. That is enough to justify testing. It is not enough to justify a production decision by itself. The defensible enterprise process is to use the model card and provider benchmarks as inputs, test the model against representative organizational work, record the exact version and configuration, quantify operational cost and failure, and build a change-control loop that assumes the next model update will arrive sooner than expected.

Updated September 2, 2026: FedRAMP 20x is no longer only a pilot or near-term transition. FedRAMP opened the Class A pipeline on August 3 and announced August 31 openings for the Class B and Class C pipelines. The FedRAMP homepage now reports 30 FedRAMP 20x certified services. For public-sector buyers, that makes the question more specific than simply asking whether a vendor is ‘FedRAMP compliant.’ Buyers should identify the exact certification class, confirm the marketplace record and service boundary, understand what evidence remains reusable, and document the agency-specific risk decision that still belongs to the agency.

What changed between the pilots and September 2026

FedRAMP describes Phase 3 of 20x as wide-scale adoption. Phase 2 tested the model at the Moderate impact level and concluded in March 2026. FedRAMP’s published lessons emphasized that automated validation and Key Security Indicators could scale, while also identifying the need for clearer assessor guidance, consistent machine-readable schemas, concise evidence context, explicit failure criteria, and assessor feedback close to the provider’s own validation evidence.

The Consolidated Rules for 2026 now provide a common rule structure for agencies, cloud service providers, assessors, and FedRAMP. FedRAMP’s July 30 certification-path update stated that Class A opened August 3 and that Class B and Class C would open August 31. Class B is the updated path associated with the previous Low level, while Class C replaces the Moderate impact path. FedRAMP also says it plans to pilot Class D, aligned with High, later in 2026 before broader availability in 2027.

That shift matters to acquisition language. A solicitation should no longer use ‘FedRAMP’ as a vague checkbox. It should state the expected certification class or acceptable transition state, the federal information and functions in scope, the service boundary, the evidence the agency expects to inspect, and any agency-specific controls or conditions that remain outside reusable FedRAMP certification evidence. Teams should verify current dates and statuses against FedRAMP’s live program pages rather than recycling acquisition language written before the 20x class model became operational.

The marketplace record is useful, but it is not the whole decision

FedRAMP’s marketplace is more important as a common discovery and status surface. It is where buyers can confirm the listed cloud service, certification class, authorizing relationships, and other program data. FedRAMP’s current homepage reports hundreds of certified cloud services overall and 30 services certified through 20x, which is evidence that the new path is moving beyond a small pilot cohort.

Marketplace data also became more operationally useful in late August. FedRAMP published a requirement, effective August 26, for providers to include general service pricing information or a link to public pricing information in marketplace data. For buyers, that creates an additional cross-check between a provider’s federal listing, its general commercial pricing context, and the actual proposal presented to the agency. It does not make procurement price analysis automatic, but it creates another public datum that should be reconciled rather than ignored.

The same FedRAMP marketplace rule set says providers must not simultaneously request both a Rev5 Program Certification and a 20x Validation for the same cloud service offering. That matters during vendor diligence because transition language can otherwise become ambiguous. Ask which path the provider is actually pursuing, what milestone has been reached, and which evidence package applies to the service being evaluated. A roadmap statement is not the same thing as a current certification state.

The certification package is becoming a living evidence set

FedRAMP’s 20x package guidance treats the certification package as maintained certification data rather than one static folder downloaded at award. Providers may expose information through trust centers, documentation portals, downloadable files, APIs, or a combination of methods. The buyer-side requirement is to understand which evidence is authoritative, how it is updated, how access is governed, and how the agency preserves the evidence it relied upon when the provider’s live portal later changes.

That should change the questions asked in demonstrations. Instead of asking whether the vendor ‘has the package,’ ask which portions are continuously maintained, which evidence is machine-readable, how changes are versioned, how agency reviewers receive updates, and what happens when evidence access is interrupted. Ask who owns the post-award evidence channel on both sides. A clean pre-award demonstration is not enough if operational staff cannot reliably retrieve the same evidence after contract signature.

A polished trust center can make evidence easier to consume, but presentation quality is not equivalent to security quality. Buyers should distinguish provider assertions, independent assessment results, continuously generated validation outputs, architecture descriptions, and agency-specific statements. The procurement file should capture enough of the relied-upon evidence to explain why the agency made its decision on that date.

Security Decision Records make traceability more important

The Consolidated Rules describe a Security Decision Record as a persistently maintained, verified, and validated record of security decisions over the lifecycle of the cloud service offering. The practical implication is not that traditional documentation disappears. It is that claims should connect more directly to decisions, implemented behavior, validation, and change.

During evaluation, ask how the provider records material security decisions and how those decisions connect to identity, network, data, logging, vulnerability, and administrative controls. Look for traceability between the declared service boundary, the decision record, automated validation, independent assessment, vulnerability information, and significant-change notifications. A control statement is more useful when reviewers can see how it is tested and what happens when the test fails.

Agencies should maintain their own decision record as well. FedRAMP certification is reusable evidence; it is not a substitute for deciding whether the service is appropriate for the agency’s intended use. Record the use case, data categories, impact assumptions, integrations, privileged paths, exceptions, compensating measures, accepted residual risk, reviewers, and conditions that force the agency to revisit the decision.

Persistent validation belongs in the vendor evaluation

FedRAMP’s 20x direction emphasizes persistent validation. Phase 2 lessons highlighted timely access, usable interfaces, consistent machine-readable schemas, concise context, clear failure criteria, assessor feedback beside provider validation, and review of validation code. Those details are procurement-relevant because they determine whether an agency can understand security posture after selection rather than only during an authorization event.

Ask vendors to demonstrate a small number of concrete validation paths. Identity configuration, vulnerability handling, boundary enforcement, and logging are useful examples. Ask what is tested, how frequently, what evidence the test creates, who reviews failures, which failures block release or trigger escalation, and which portions were independently assessed. The goal is not to prescribe one security tool. It is to establish that the provider can turn security expectations into repeatable evidence.

Machine-readable evidence may also support agency portfolio oversight. An agency operating many cloud services may want to ingest status data, certification metadata, vulnerability information, or change notifications into GRC, vulnerability, incident, or architecture workflows. Contract teams should identify those interface and access needs early so a PDF-only process does not become an avoidable bottleneck later.

Vulnerability, change, and exit evidence deserve contract language

The 2026 rules include updated expectations for vulnerability detection and significant changes. Buyers should translate those program requirements into service-management interfaces: where notifications arrive, which events require action, what fields are included, what severity or timing information is available, and how the agency can subscribe through an inbox, portal, API, or ticket integration.

Do not accept the phrase ‘continuous monitoring’ without identifying the receiver and escalation path. The agency needs to know which team receives provider information, how it enters incident and vulnerability workflows, how exceptions are tracked, and how material changes reach architecture or authorization reviewers. Contract language should assign ownership on both sides.

Exit and continuity belong in the same evidence discussion. Ask how the agency obtains records, logs, configuration information, audit history, and agency data at termination; how long security evidence remains available after the relationship ends; and how access changes during transition. Initial certification quality does not eliminate operational risk if the agency cannot preserve the information needed for investigations, records obligations, migration, or handoff.

A stronger public-sector evidence request

For a material cloud procurement, request the exact FedRAMP marketplace listing or certification path, current class and status, declared service boundary, evidence-sharing method, and independent assessment information appropriate to the offering. Then request the architecture view, identity and administrative model, data flows, encryption approach, audit and logging capabilities, vulnerability process, incident-notification process, significant-change process, and post-award evidence-access model.

Ask for examples that show how the process works, not only policy statements: a redacted validation result, sample significant-change notice, sample vulnerability status record, audit event, failure criterion, or explanation of how a Security Decision Record changes after an architectural change. The objective is not to recreate FedRAMP’s assessment. It is to obtain enough relevant proof to support the agency’s own purchasing and authorization decision.

Zeph Tech’s Vendor Security Questionnaire can structure the security evidence request, while the Software Evaluation Scorecard helps preserve comparable evidence across competing offerings. For larger acquisitions, the Public-Sector Technology Procurement Toolkit carries the same decision into requirements, accessibility, migration, continuity, and exit planning.

Questions for the next procurement or architecture review

• Which FedRAMP certification class and current marketplace status apply to this exact cloud service offering?
• Is the provider pursuing 20x or Rev5 for this offering, and what transition assumptions are embedded in the proposal?
• Can reviewers access current certification evidence before award, and will that access continue after award?
• Which security assertions are persistently validated, and what happens when validation fails?
• How will vulnerability, incident, and significant-change information enter the agency’s own workflows?
• Can the agency preserve the evidence it relied on when live provider documentation changes?
• What agency-specific controls, integrations, or risk decisions remain outside reusable FedRAMP evidence?
• What change in scope, data, architecture, ownership, or certification state forces a new agency review?

FedRAMP 20x can make federal cloud security evidence more current and more reusable, but it does not remove disciplined buying. The strongest procurement process uses FedRAMP as one authoritative evidence layer, defines the agency decision that evidence must support, preserves a traceable record of the decision, and establishes how risk information will keep flowing after award.

Updated September 2, 2026: Accessibility belongs in software procurement before the demo, not in remediation after go-live. For U.S. federal agencies, Section 508 requires information and communication technology that agencies procure, develop, maintain, or use to conform to the Revised 508 Standards unless an applicable exception is documented. GSA’s current Section508.gov guidance continues to frame accessibility as an acquisition-lifecycle responsibility spanning requirements, market research, solicitation language, vendor evidence, evaluation, acceptance, and post-award validation. Buyers should treat an Accessibility Conformance Report as evidence to examine—not a checkbox that ends the review.

Start with the legal baseline, then define the product standard you actually need

Federal acquisition teams should distinguish the Revised 508 Standards from newer web accessibility guidance. Section508.gov’s materials describe the Revised 508 technical requirements as aligned with WCAG 2.0 Level A and Level AA. WCAG 2.2 is a newer W3C Recommendation and adds success criteria including Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, and Accessible Authentication. W3C recommends using the latest WCAG version where possible, but that does not mean a buyer should rewrite the federal legal baseline as if Section 508 itself simply equals WCAG 2.2.

A strong solicitation separates mandatory requirements from additional accessibility goals. Identify which Revised 508 provisions apply to each ICT component, document any legitimate exception analysis, and then state any additional contract requirements the agency wants the solution to satisfy. If WCAG 2.2 AA is a contractual or design objective beyond the incorporated federal baseline, say so explicitly and define how it will be tested. Clear requirements reduce disputes later about whether a vendor promised legal conformance, broader best-practice conformance, or both.

This distinction also improves market research. Vendors may publish ACRs based on different VPAT editions and different technical standards. Compare the report’s stated standard, product version, module, and evaluation date to the actual solicitation. An impressive accessibility landing page does not prove that the specific version, configured implementation, mobile experience, authoring workflow, or integration being purchased meets the agency’s requirements.

Request an ACR, but evaluate what is inside it

Section508.gov advises federal buyers to request accessibility information from vendors and contractors. For standard commercial or government off-the-shelf ICT, an ACR provides a structured way to describe conformance. Buyers should read the product name, version, report date, scope, evaluation methods, applicable standards, and remarks before treating the conformance labels as meaningful.

Pay particular attention to Partially Supports, Does Not Support, Not Applicable, and similar entries. The remarks should identify the affected function, the condition under which the barrier appears, and any workaround or remediation path. A report containing uniformly positive conclusions but little test detail deserves more scrutiny, not less. The buyer should be able to tell what was actually evaluated.

Freshness matters because software changes continuously. Ask what product build the report covers, whether material interface changes occurred after the report, and what event triggers an updated ACR. For SaaS, accessibility evidence maintenance belongs in the ongoing contract relationship. A report for a materially different interface is historical evidence, not proof of the current service.

Use the newer ACR supplement to ask better defect questions

Section508.gov’s Government ACR Supplement, reviewed in August 2026, gives buyers a more operational model for accessibility gaps. It asks for the affected product area or workflow, impacted user group, workaround, and related defect context instead of relying only on a conformance label. That is a useful procurement pattern even when the exact supplement is not contractually required.

When a vendor discloses a gap, ask four questions: what user task is affected, which users experience the barrier, whether a realistic workaround exists, and when the product team expects to remediate and retest the problem. A defect such as unlabeled form fields, an inaccessible address workflow, or a keyboard trap should be described in terms of functional impact rather than buried in generic remarks.

This also helps buyers compare risk across vendors. One product may have more disclosed defects but better evidence, clearer ownership, and dated remediation. Another may report near-perfect conformance with little test detail. Procurement scoring should reward evidence quality and realistic remediation governance rather than incentivizing vendors to disclose less.

Test the workflow, not only isolated pages

Accessibility problems often appear at the boundaries between components: authentication, modal dialogs, file upload, document preview, tables, charts, date pickers, search filters, notification banners, generated PDFs, rich-text editors, or third-party integrations. A procurement evaluation should therefore use representative end-to-end workflows rather than checking only a landing page.

Choose tasks that matter to actual users. For a records system, that may include signing in, finding a record, filtering a table, opening an attachment, editing metadata, completing a form, receiving validation feedback, exporting a report, and signing out. For a public portal, include search, pagination, document access, form submission, status messages, and mobile use. For an internal workflow application, include keyboard-only operation and assistive-technology interaction with the highest-volume and highest-consequence tasks.

Automated scanning is useful but cannot establish full conformance. Combine it with keyboard review and appropriate manual or assistive-technology testing. Document the test environment, browser, platform, assistive technology where used, product build, test steps, expected result, actual result, severity, and disposition. The evidence should be reproducible enough that agency and vendor reviewers are discussing the same defect.

Use accessibility as an acceptance criterion, not only a pre-award promise

Section508.gov frames procurement as a lifecycle that continues after award. Put measurable accessibility acceptance criteria into the statement of work, quality plan, backlog definition of done, or other appropriate contract artifact. Define what must be tested before release, who performs the testing, which evidence the contractor supplies, which severity levels block acceptance, how remediation is tracked, and how retesting occurs.

Configured and custom solutions deserve special attention. A platform can provide accessible components while an agency or implementation partner creates inaccessible forms, documents, labels, reports, or extensions. Conversely, accessible source content can become inaccessible when rendered by the product. The contract should identify ownership for standard components, configured workflows, authored content, integrations, generated documents, training, and final acceptance.

Accessibility should also appear in quality surveillance. If a release materially changes navigation, authentication, core workflows, document output, or a major UI component, define whether that change triggers regression testing or an updated ACR. Treating accessibility as part of normal release governance is more sustainable than reopening a one-time compliance project after users report barriers.

Ask about remediation and product governance before you need them

No mature buyer should assume a complex product will never have an accessibility defect. The procurement question is how the vendor finds, prioritizes, communicates, and fixes defects. Ask for the accessibility intake path, severity model, remediation targets, release process, regression approach, customer-notification practice, and product owner. Ask whether accessibility findings live in the same product-management system as other defects or disappear into an unowned compliance queue.

For known gaps, request a remediation plan identifying the affected function, user impact, workaround, target release, owner, and validation method. Avoid undated commitments. If a gap affects a core task, determine before award whether an alternate means of access is realistic for the user population and operational setting. Section508.gov’s procurement guidance discusses best-meets situations where no technically acceptable commercial alternative fully conforms, but that is a documented acquisition decision—not a blanket waiver of accessibility expectations.

Governance should survive product change. Contract terms can require notice when a release materially changes an accessibility claim, replaces a major component, or causes an ACR to be updated. The agency should have a named accessibility owner or review function that receives those changes and determines whether new testing is required.

WCAG 2.2 strengthens evaluation without changing the legal label

WCAG 2.2 provides useful additional tests for modern interfaces. Focus Not Obscured is relevant to sticky headers and overlays. Dragging Movements matters when essential functions depend on drag-and-drop. Target Size matters for dense interfaces and mobile use. Accessible Authentication matters when login flows introduce cognitive-function tests or other avoidable barriers. These are practical design and procurement signals even when the mandatory Section 508 baseline remains tied to the Revised 508 Standards.

If an agency chooses to require WCAG 2.2 AA contractually, define scope: standard product, configured implementation, public content, internal administration, mobile web, native applications, generated electronic documents, or all of them. Then define testing and acceptance. A sentence that says ‘must be WCAG compliant’ is ambiguous because it omits version, level, product scope, exceptions, and evidence.

For non-federal public-sector buyers, the controlling legal requirements may differ by jurisdiction. The evidence discipline remains useful: identify the applicable rule, define scope, request a conformance statement, test material workflows, document gaps, and place remediation and regression expectations into the operating relationship.

A buyer evidence pack for accessible software

Ask each shortlisted vendor for the current ACR covering the product and version proposed, the methods used to produce it, known accessibility defects affecting material workflows, remediation governance, and the accessibility product contact. For custom development or configuration, request the accessibility test plan, development standards, component or design-system practices, and evidence that accompanies each release.

During evaluation, preserve the ACR version and date, workflow-test notes, demonstrations, defect list, vendor clarifications, remediation commitments, exception decisions, and scoring rationale. Connect those items to the procurement record rather than storing them in an isolated accessibility folder that reviewers never see during award.

Zeph Tech’s Accessibility Procurement Checklist can structure that evidence request. The Software Evaluation Scorecard makes accessibility findings visible alongside security, implementation, support, and exit risk, while the Public-Sector Technology Procurement Toolkit carries the same evidence through a broader acquisition lifecycle.

Questions for the next software evaluation

• Which Revised 508 provisions apply to each ICT component being purchased?
• What exact product version and technical standard does the ACR cover?
• Which material workflows were manually tested, and can the vendor demonstrate them with keyboard and assistive technology?
• For each known gap, what task is affected, which users are impacted, what workaround exists, and what dated remediation commitment is recorded?
• Are we intentionally requiring WCAG 2.2 beyond the federal baseline, and have we defined scope and acceptance?
• Who owns accessibility for custom configuration, third-party components, generated content, documents, and integrations?
• What product change triggers an ACR update or agency retest?
• Will accessibility defects affect acceptance, quality surveillance, and contractor performance after award?

An ACR is valuable because it creates a structured starting point for the conversation. It is not a substitute for requirements, workflow testing, acceptance, or ongoing oversight. The strongest procurement process makes accessibility visible from market research through post-award operations, preserves evidence at each stage, and distinguishes clearly between the legal baseline and any higher design standard the agency chooses to require.

Updated September 2, 2026: The EU AI Act became broadly applicable on 2 August 2026, but the implementation picture is not the one many 2024 compliance plans assumed. Regulation (EU) 2026/1744, the Digital Omnibus on AI, changed the timetable for high-risk systems shortly before the main application date. The result is a split calendar: many governance and transparency duties are active now, some amended prohibited-practice and synthetic-content provisions take effect in December 2026, general-purpose AI obligations have applied since August 2025, and the principal high-risk-system requirements move into 2027 and 2028. Organizations should update control maps to the amended law instead of treating every obligation as either fully live or uniformly delayed.

What is already live in September 2026

The AI Act’s general application date remains 2 August 2026. The consolidated legal text shows Chapters I and II applying from February 2025 subject to newly amended exceptions, Chapter III Section 4 and several other governance and enforcement provisions applying from August 2025, and Articles 102 through 110 applying from 27 July 2026. The practical point is that the Digital Omnibus changed selected dates; it did not suspend the entire AI Act.

Organizations should therefore maintain an inventory that distinguishes legal role, intended purpose, system category, geography, and obligation family. A provider, deployer, importer, distributor, and authorized representative do not inherit the same responsibilities. Those roles depend on facts such as who places the system on the market, whose name or trademark is used, who substantially modifies the system, and how the system is actually deployed.

Transparency work should be treated as an operating control. Teams need to know where people encounter AI, where synthetic or manipulated content is produced or published, who owns disclosures, and how the disclosure is tested across interfaces and channels. A policy document is weak evidence on its own. Stronger evidence connects the inventory record to the product surface, disclosure text, owner, test result, exception rationale, and change trigger.

December 2, 2026 is the next near-term transition date

The Digital Omnibus added a specific transition for providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video, or text content and were placed on the market before 2 August 2026. Those providers must take the necessary steps to comply with Article 50(2) by 2 December 2026. That makes synthetic-content provenance and marking a near-term engineering issue rather than something organizations can postpone until the later high-risk dates.

The amendment also moved selected prohibited-practice provisions added by the Digital Omnibus to 2 December 2026. Teams maintaining policy maps should therefore avoid a single status field that says ‘Article 5 active’ without identifying the paragraph and amendment involved. The safest operating record captures the specific article, applicability date, system facts, control owner, and evidence location.

For product teams, the useful question is whether a December deadline requires an actual technical or release change. If a system generates synthetic content, document the current output-marking mechanism, downstream transformations that could remove or alter it, API behavior, supported formats, customer responsibilities, and testing evidence. Where the organization is a deployer rather than the provider, preserve the provider’s documentation and identify which additional disclosure duties belong to the deployment context.

The Digital Omnibus moved the principal high-risk deadlines

Regulation (EU) 2026/1744 amended Article 113 so that Chapter III Sections 1, 2, and 3—other than the specified Article 6(5) exception—apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I. The law explains that delayed standards, specifications, guidance, and national-authority readiness contributed to the revised timetable.

This is a legal delay, not evidence that preparatory work has no value. A provider waiting until the final quarter before the deadline will still need to confirm classification, establish data-governance controls, produce technical documentation, design logging, define human oversight, validate accuracy and robustness, connect cybersecurity testing to release governance, and establish post-market monitoring. Those activities can depend on procurement, architecture, engineering, and assurance cycles that are much longer than a few months.

The amended timetable makes classification discipline more important. Annex III use cases and Annex I product-related systems now have different principal dates. A single spreadsheet field called ‘high risk’ is therefore inadequate. Record the classification basis, article and annex reference, system role, geography, evidence owner, review date, and the event that would force reclassification.

Public-authority high-risk deployments have an additional transition point

The amended text also states that providers and deployers of high-risk AI systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 in the relevant transition provision. Public-sector teams should not read that outer date as permission to ignore current procurement and architecture decisions. Systems procured now can remain in service for years, and contract terms established in 2026 may determine whether the authority can later obtain documentation, logs, testing evidence, version information, and remediation support.

For public-sector procurement, use the longer horizon to improve contract quality. Request role analysis, intended-purpose documentation, model and version information, data-flow information, human-oversight capabilities, logs, evaluation evidence, incident notification, material-change notice, and exit data. Make the evidence refreshable so the authority is not trying to reconstruct a 2026 procurement record in 2029.

Zeph Tech’s Public-Sector Technology Procurement Toolkit and Vendor Security Questionnaire can be used to preserve those evidence requests alongside the broader acquisition record rather than treating AI compliance as a separate legal attachment.

Earlier obligations still matter

AI-literacy duties and many prohibited-practice rules began applying in February 2025. Governance rules and obligations for providers of general-purpose AI models began applying in August 2025. The Digital Omnibus did not erase those earlier dates. Organizations should preserve evidence of training, prohibited-use controls, model-provider due diligence, escalation procedures, and role-specific governance rather than rebuilding the program only around the revised high-risk timetable.

AI literacy should reflect actual responsibilities. Procurement staff need to recognize product claims and contract gaps. Developers need to understand evaluation, logging, data handling, and misuse boundaries. Frontline deployers need to recognize where AI output cannot simply become a decision. Risk and legal reviewers need enough technical context to challenge intended-purpose and classification statements. Attendance records are useful, but role-specific objectives and practical checks are stronger evidence.

General-purpose AI governance also requires a supply-chain view. Record the model and version, provider terms, data-use settings, hosting route, retrieval sources, tools or actions the model may invoke, output destinations, and the trigger for re-evaluation. A deployer may depend on model-level documentation from a provider while remaining responsible for its own interface, instructions, monitoring, and downstream use.

A practical 30-day control reset

First, reconcile the AI inventory with the amended dates. Replace blanket ‘August 2026’ status labels with the specific obligation family that applies. Confirm whether each system implicates prohibited practices, transparency, general-purpose AI, potential Annex III high-risk use, Annex I product-related use, or none of those categories. Preserve uncertainty where classification is not yet resolved.

Second, inspect public and employee-facing experiences for transparency and synthetic-content handling. Capture test evidence showing disclosures or marking in context. Review generated-content workflows in marketing, support, public information, knowledge bases, document generation, and API-based publication. Assign an owner for changes in model behavior or delivery channel that could invalidate the current control.

Third, review contracts and vendor evidence. Ask for model cards or equivalent documentation, intended and excluded uses, data handling, retention, subprocessors, security controls, incident notification, version-change practices, evaluation evidence, logging support, and technical documentation. A vendor statement that a product is ‘AI Act compliant’ is not a substitute for evidence relevant to the buyer’s role and use case.

Finally, create a dated decision record that identifies the business owner, technical owner, risk owner, legal interpretation source, classification rationale, current controls, open gaps, next review event, and accountable approver. Link the record to evidence rather than duplicating unsupported conclusions across systems.

The evidence pack leadership should ask to see

For a material AI use case, leadership should be able to inspect an inventory record, role analysis, intended-purpose statement, data-flow or architecture view, model and vendor documentation, evaluation plan, test results, transparency evidence, human-oversight design, incident path, monitoring indicators, and a record of accepted residual risk. The pack should distinguish vendor-supplied facts from findings produced by the organization.

Useful metrics include the percentage of systems with a current owner, percentage with a dated classification rationale, evaluation coverage after material changes, unresolved high-severity findings, disclosure test coverage, time to disable or contain a problematic deployment, and incomplete vendor evidence requests. A count of ‘AI projects reviewed’ has little meaning if the review standard is undefined.

The Software Evaluation Scorecard can be used to make these evidence differences visible during a technology decision, while the Evaluation Brief Builder helps turn an AI use case into concrete questions before a vendor conversation.

Decision questions for the next steering meeting

• Which obligations are active for this system today, and what article-level basis supports that conclusion?
• Do any synthetic-content systems need a technical or operational change before 2 December 2026?
• Which systems depend on the 2027 Annex III or 2028 Annex I timetable, and what engineering lead time remains?
• Which public-authority deployments may rely on the later transition provision, and are current contracts preserving the evidence needed before 2030?
• Where are we relying on vendor assurances without documentation relevant to our own legal role?
• Can we trace every material system to an owner, intended purpose, model or version, data boundary, evaluation, and incident path?
• What change—new model, new data, new user group, new action, new geography, or substantial modification—forces reclassification or re-evaluation?

The practical advantage of the revised timetable is the opportunity to replace hurried checkbox work with an evidence-producing operating model. The organizations that use the extension well will arrive at the later high-risk deadlines with tested controls, current supplier evidence, and repeatable review habits. Organizations that read ‘delay’ as ‘do nothing’ will face the same engineering and governance work later with less time and weaker institutional memory.

this analysis is an implementation aid, not legal advice. Validate material decisions against the consolidated EU legal text, current Commission guidance, and qualified counsel for the relevant role and jurisdiction.