Summary

  • MOVEit became a trust-boundary accountability problem because the affected product was a managed file-transfer system used specifically to move sensitive files between organizations, suppliers, customers, and public programs.
  • Progress's May 31 advisory for MOVEit Transfer Critical Vulnerability CVE-2023-34362, its customer FAQ, and its July 2023 Form 10-Q anchor the vendor chronology and the limits of on-premises visibility.
  • CISA's Known Exploited Vulnerabilities entry, CISA and FBI's #StopRansomware advisory, and NIST's NVD record show why this quickly became a public defensive emergency, not only a vendor-support matter.
  • Affected-organization records such as Nova Scotia's public report, NYC Public Schools' incident page, CMS's contractor breach notice, and CalPERS's third-party breach notice show how one transfer flaw cascaded into many separate notification duties.
  • The repair test is not whether Progress issued patches. It is whether the product owner, operators, and data controllers could find exposed instances, patch quickly, investigate theft, minimize retained transfer data, notify downstream people, and prove that sensitive transfer systems were no longer left exposed.

A transfer product is a promise about boundaries

Managed file transfer has a plain business promise: sensitive files can move between organizations in a controlled, auditable, trusted way. That promise is why the MOVEit incident was so damaging. The product was not an incidental website. It was a boundary system. Organizations used it because ordinary email, ad hoc file sharing, and unmanaged transfer channels were not adequate for the sensitivity, volume, or workflow around the data being moved.

Progress's May 31, 2023 advisory for MOVEit Transfer Critical Vulnerability became the starting point for that boundary failure in the public record. The company's later MOVEit Transfer and MOVEit Cloud Patch FAQ summarized CVE-2023-34362 and follow-on vulnerabilities, while Progress's June 5 update on steps to protect MOVEit customers described cloud shutdown, patch validation, audit-log review, and customer guidance. These vendor records show the first repair layer: notice, mitigation, and patching.

The accountability issue starts where the first repair layer ends. A patch can close a vulnerability, but it does not tell an operator whether data was already stolen. It does not tell a pension system which retirees were exposed. It does not tell a school system which student files were copied. It does not tell a government contractor how to notify a federal agency. It does not erase a web shell. It does not determine whether old files should have been retained on the transfer server at all.

That is why MOVEit should be read as a trust-boundary collapse. Sensitive transfer systems often sit between parties. A company may operate the server; a supplier may use it; a public agency may control the underlying data; individuals may never know their records passed through it. When the transfer layer fails, responsibility does not sit neatly in one place. The vendor controls product security and advisories. The operator controls patching, exposure, retention, and investigation. The data controller controls notice and minimization duties. The affected person carries the risk.

The hard part is that every party can point to a partial boundary. Progress can say customers must patch and investigate their own deployments. Operators can say they relied on a trusted product. Data controllers can say a vendor or contractor processed the files. Individuals can say they never chose any of this. Accountability has to connect those partial boundaries back into a working chain.

Vendor telemetry limits were part of the public risk

Progress's July 2023 Form 10-Q is important because it described a May 28 customer call, May 30 discovery, cloud shutdown, May 31 patches, customer notice, and the company's lack of continuing telemetry into on-premises customer deployments. That last point is not a criticism by itself. Many on-premises products are deliberately customer-operated. But during mass exploitation, telemetry limits become public risk because the vendor cannot directly tell every customer whether their instance was compromised.

On-premises control creates a split accountability model. Customers control deployment, internet exposure, patch windows, logging, backups, retention, and investigation. The vendor controls secure development, disclosure, patch quality, product documentation, and support. During normal operations this split may be acceptable. During zero-day exploitation it becomes painful, because the people most exposed may not know fast enough.

Progress's June 13 update on enhancing MOVEit Transfer security through partnership and transparency described additional code review, discovery of CVE-2023-35036, and collaboration with Huntress. Progress's release documentation for what was new in MOVEit Transfer 2023 and fixed issues in 2023 helps anchor the patch sequence. These records matter because patch clarity is one of the few tools a vendor has when it cannot see every customer server.

But patch clarity still depends on customer inventory. Does the organization know every MOVEit instance? Is it exposed to the internet? Which version runs? Who owns it? Which files sit there? Which logs are retained? Which contractors use it? Which downstream data controllers must be told if theft is suspected? The moment exploitation becomes public, those questions become urgent.

The MOVEit record shows that software accountability is not only code quality. It is also the ecosystem around the code: update distribution, customer detection guidance, telemetry design, instance inventory, internet exposure management, and incident-handling instructions. A vendor that sells a sensitive transfer product has a strong duty to make those ecosystem responsibilities legible before the crisis, not only during it.

Known exploitation compressed patch time

CISA added CVE-2023-34362 to its known exploited vulnerability catalog, visible through the CISA KEV entry. CISA and FBI then issued the #StopRansomware advisory on CL0P exploitation of CVE-2023-34362, with indicators and defensive recommendations. NIST's NVD record documented the vulnerability record and exploitation status. These government sources show how quickly the incident left ordinary patch-management tempo behind.

The UK National Cyber Security Centre's MOVEit vulnerability and data extortion incident and the UK Financial Conduct Authority's MOVEit vulnerability statement reinforce the same point for regulated and public-interest environments. Organizations could not treat the issue as a quarterly maintenance task. They had to identify exposure, follow vendor guidance, review logs, assess compromise, and begin notification analysis under compressed time.

Compressed patch time exposes organizational weakness. Many organizations know how to apply routine updates. Fewer can perform emergency discovery across production, legacy, test, and vendor-hosted environments. Fewer still can determine which sensitive files passed through a system in a relevant window, whether files were retained unnecessarily, and which individuals or agencies must be notified. The patch is only one step in a chain of evidence.

The trust-boundary problem is especially sharp because MOVEit systems often held data from multiple parties. A server might include files uploaded by one agency, processed by a contractor, sent to another entity, and tied to individuals across jurisdictions. If attackers copied files, the notification duty may not track the server owner alone. It may track data controllers, affected populations, and contractual commitments. This is why mass exploitation of a transfer product generates many separate notices.

Patch time also interacts with public communication. If an organization patches quickly but does not know whether theft occurred, it must avoid false reassurance. If it delays communication until file review is complete, affected people may wait months. The accountable middle is staged notice: immediate exposure mitigation, clear investigation status, later data-scope findings, and individual notice when facts support it.

Security-company visibility helped, but did not replace operator proof

Mandiant's report on zero-day MOVEit data theft described exploitation observed as early as May 27, web shell and theft behavior, infrastructure observations, and attribution context. Rapid7's timeline of CVE-2023-34362 events cross-checked patch and exploitation chronology. Huntress's rapid response analysis added exploit-chain capability, host artifacts, and local investigation tips.

These sources were useful because they gave defenders practical indicators and context while the incident was unfolding. But they could not replace local proof. An organization still needed to inspect its own server, logs, files, retention history, backups, network traces, and downstream data ownership. A public indicator list helps find suspicious artifacts; it does not prove absence of theft in a particular environment.

Censys's MOVEit Transfer exposure analysis and later industry analysis showed why exposure measurement is useful but limited. Scanner observations can identify internet-facing services and trends. They cannot reliably prove each service's version, vulnerability, ownership, compromise status, or data sensitivity. Exposure counts are a map of possible risk, not a verdict.

Emsisoft's public analysis, Unpacking the MOVEit breach, provided a broad tally of known organizations and individuals compiled from public notices, filings, disclosures, and the criminal leak site. It is valuable as scale evidence. It is not an official census. Downstream customers may overlap, individual counts may be defined differently, and criminal claims vary in reliability.

The article should therefore keep evidence layers separate. Vendor advisories tell customers what to do. Government advisories confirm known exploitation and provide defensive guidance. Security companies describe observed techniques and exposure. Affected organizations disclose their own impact. None of those layers alone can answer the whole accountability question. The repair record emerges only when they are reconciled.

Typography note

Downstream notices show the real shape of the failure

The affected-organization record is where the trust-boundary problem becomes human. Nova Scotia's public report on the cyber security attack on Nova Scotia's MOVEit system described a detailed response chronology and the theft window in that environment. The Nova Scotia privacy commissioner's Investigation Report IR25-01 made independent findings about privacy impact assessment, over-retention, repository misuse, notices, and recommendations. Those findings apply to Nova Scotia, not every victim. But they show the kind of local accountability a transfer incident requires.

NYC Public Schools' MOVEit data-security incident page described copied files, data categories, and the boundary that other department network areas were not accessed. CMS's notice on responding to a data breach at a contractor described the Maximus contractor context and Medicare beneficiary exposure. CalPERS's third-party breach notice described retiree-information exposure through supplier chain. Each notice is narrow. Together they show the failure's shape: a product-layer vulnerability became many local data-governance problems.

The local problem is often data scope. What files were on the server? Were they current? Were they temporary transfer files or long-retained repositories? Did they include health, pension, student, employee, financial, or identity data? Were files encrypted before upload? Who controlled deletion? Which downstream entities had to be told? The technical exploit opens the door; the retention and data-governance choices decide what attackers can carry away.

Nova Scotia's privacy findings are especially useful because they move beyond "we were affected by MOVEit" into questions about privacy impact assessment and retention. That is the right direction. A transfer server should not become a permanent warehouse unless the organization has a clear purpose and protection plan. The more sensitive data remains in a transfer zone, the more a product vulnerability becomes a broad privacy event.

Other organizations may have had stronger or weaker practices. The public record does not allow one operator's findings to be generalized as a universal legal conclusion. It does support a general accountability standard: after a managed-transfer exploit, every operator should be able to show why each file was present, how long it needed to remain, who could access it, and how quickly theft scope was determined.

Data locality becomes harder when transfer chains are opaque

The MOVEit campaign also raised data-sovereignty and locality questions, even when a particular notice did not prove cross-border storage. A transfer product can move files among agencies, contractors, pension administrators, schools, health programs, payroll processors, and vendors. The physical location of the server is only one question. The more practical question is which organization had control over the file at each moment and which legal regime governed notice after the file was copied.

Data locality is often discussed as a cloud-region issue. Managed file transfer shows a different locality problem: the path may be temporary, contractual, and multi-party. A pension record may travel from a public entity to a supplier. A school record may sit in a transfer folder for a contractor. A health-benefit file may be processed by a program administrator. If the transfer system is compromised, affected individuals may learn about a chain they never saw.

The UK NCSC and FCA materials show that regulators expected organizations to understand both direct and third-party exposure. That is the right standard. An organization cannot stop at "we do not run MOVEit" if its data passed through a supplier's instance. Nor can a supplier stop at "the product was vulnerable" if it retained files longer than needed or delayed notice to data controllers.

For global organizations, the chain can cross borders. The public evidence in any one notice may not reveal where every file sat or moved. Responsible analysis should avoid inventing data locations. But accountability does not require invented locations. It requires organizations to document the transfer path well enough to answer the locality question quickly when an incident occurs.

The repair record should therefore include transfer-chain mapping. Which business process uses the transfer product? Which counterparties upload or download files? Which jurisdictions' data appears? Which contracts allocate notice, deletion, encryption, and investigation duties? Which files are automatically purged? Which exceptions are reviewed? A transfer system without that map is a trust boundary built on memory.

Patch release did not prove cleanup

One of the strongest lessons from MOVEit is that patch release and cleanup are different obligations. Progress issued advisories and patches. Customers had to apply them. But if exploitation occurred before patching, the operator still needed to remove malicious files, review logs, determine data access, preserve evidence, notify affected parties, and reconsider retention. Patching closes one door. It does not show what came through before it closed.

This distinction is familiar to incident responders but often missing from public discussion. A board may ask, "Are we patched?" That is necessary. The next question is, "Were we compromised before patching?" Then, "What data was present?" Then, "Can we prove it?" Then, "Who must be notified?" Then, "What changes reduce data at risk next time?" Without that sequence, patch compliance can become a false finish line.

MOVEit made the problem harder because exploitation was broad and the product was often internet-facing. CISA's KEV catalog compressed remediation expectations, but many organizations had to conduct forensic review under stress. Some may have lacked logs. Some may have had third parties operate instances. Some may have had old files in transfer folders. Some may have needed to notify many downstream groups. The technical patch was only the beginning of organizational repair.

Progress's later 2024 release announcing the conclusion of the SEC investigation is part of the accountability record, but it does not close every other track. SEC staff decisions, private litigation, regulator reviews, customer notice, and data-controller duties have different scopes. A company can avoid one enforcement recommendation while affected organizations still owe people clear notice and while operators still need to improve retention.

This layered closure matters. Product-vendor accountability, customer-operator accountability, and data-controller accountability run on different clocks. The public needs to know which clock is being discussed. "Progress patched" is not "all operators cleaned." "No SEC enforcement recommendation" is not "no customer harm." "A notice was mailed" is not "retention was fixed." The article's central job is to keep those statements from being blurred.

Transfer systems need retention discipline

The most important non-patch lesson is retention. Managed file transfer is often treated as a secure conduit, but in practice transfer folders can become repositories. Files remain because deletion is inconvenient, because no one owns the cleanup job, because an integration needs retry capability, because auditors want history, because counterparties forget, or because the system is quietly used as storage. That drift turns a transfer vulnerability into a data-minimization failure.

Retention discipline should be built into the product and the process. Files should have default expiration. Exceptions should be explicit. Sensitive transfer folders should be reviewed. Logs should preserve enough evidence without retaining payloads longer than needed. Contracts should specify deletion and data-return rules. Data controllers should know whether suppliers keep transfer copies. Operators should be able to answer, within hours, what data categories were present during a compromise window.

The Nova Scotia privacy report shows why this is not abstract. It identified local privacy-governance issues and recommendations after the MOVEit incident. Other organizations may not have the same findings, but every organization can learn from the pattern. The product vulnerability was the trigger; retained data determined the blast radius.

Encryption also needs careful framing. Encrypting files before transfer can reduce exposure, but only if keys are not accessible through the same compromised path and the business process can still function. Transport encryption does not help if attackers reach stored plaintext after upload. Tokenization, minimization, and field-level controls may reduce harm, but only when designed into the workflow. A transfer product does not automatically make the data safe simply because it is a security-focused product.

The accountability standard is therefore boring and exacting: know the files, minimize the files, expire the files, log the access, test the deletion, and rehearse the notice path. In a trust-boundary product, boring controls are the difference between a contained exploit and a mass disclosure.

Customers need evidence, not only advisories

During the incident, customers needed to know whether they were exposed, whether they were vulnerable, whether they were exploited, whether data was stolen, whether patches were complete, and whether follow-on vulnerabilities affected them. Advisories can provide general instructions. Customers still need environment-specific evidence. That evidence may come from logs, files, web shell scans, network records, vendor support, third-party forensics, or data-review teams.

The vendor can help by making the evidence path clear. What logs matter? Where are indicators located? Which versions need which patches? Which artifacts suggest compromise? Which mitigations are temporary? How should customers treat cloud versus on-premises deployments? What is known and unknown about exploitation? Which follow-on vulnerabilities have observed exploitation and which do not? Progress's FAQ and updates attempted to answer some of these questions. The accountability question is whether customers could operationalize those answers quickly enough.

Customers can help themselves by preparing before a crisis. They should maintain a current inventory of transfer systems, exposure status, version, owner, data categories, retention rules, counterparties, and log retention. They should define who can shut a transfer system down, who informs counterparties, who reviews files, who handles notice, and who coordinates with law enforcement or regulators. They should test whether the inventory is accurate.

Supplier contracts should also define evidence duties. A contractor operating MOVEit for a public agency should know how quickly it must notify the agency, what logs it must provide, how data scope will be reviewed, who pays for notice, and how retention will be managed. Without those terms, the incident response becomes a negotiation while affected people wait.

The MOVEit episode showed that data-sharing infrastructure can become a common failure path across unrelated organizations. That is not a reason to abandon managed transfer. It is a reason to govern it as a high-risk boundary. The stronger the product promise, the stronger the evidence obligations when it fails.

The durable lesson is boundary proof

The final accountability question is whether the boundary can be proven. Before the incident, many organizations treated MOVEit as a trusted place to move sensitive files. After the incident, trust had to be reconstructed from evidence: patch status, logs, indicators, file lists, retention schedules, notices, and remediation actions. Trust was no longer a product claim. It was an audit trail.

For Progress, the durable repair record is secure-development review, clear advisories, patch quality, customer guidance, and product features that make safer operation easier. For operators, it is inventory, emergency patch capacity, exposure management, logging, retention discipline, compromise assessment, and downstream notice. For data controllers, it is knowing where sensitive files move and ensuring contracts preserve visibility. For affected people, it is receiving accurate, timely, understandable notice when their data crosses a compromised boundary.

No single party can repair the whole ecosystem alone. But each party can stop hiding behind the others. A vendor cannot say only that customers should patch when the product is designed for sensitive transfer. An operator cannot say only that the vendor had a flaw when the operator retained data and exposed the service. A data controller cannot say only that a contractor handled the file when the people affected trusted the controller's program. Accountability is the discipline of joining those partial truths.

MOVEit belongs in a risk and accountability record because it reveals how modern data sharing works. Sensitive information moves through specialized tools, between organizations, under contracts people never see, and across systems that may be operated far from the individual whose data is inside the file. When the transfer boundary fails, the public needs more than patch headlines. It needs proof of what crossed, who knew, who notified, what changed, and why the next transfer boundary should be trusted.

Notification cascades need their own evidence chain

The MOVEit incident produced many public notices because the data relationships were layered. A product vendor disclosed a vulnerability. Operators assessed servers. Contractors notified customers. Public agencies and pension systems notified affected populations. Individuals received letters from organizations that may not have directly operated the transfer product. That notification cascade can be legitimate, but it creates a second accountability problem: each notice depends on evidence from another party.

Nova Scotia's public incident report is useful because it shows how a single operator had to reconstruct a chronology, identify file access, patch, shut down, resume, and report. The later Nova Scotia privacy commissioner investigation report adds a different layer by examining privacy governance and response quality. Those two documents together demonstrate that notification is not merely a mail merge. It is an evidence chain.

The same pattern appears in other affected records. NYC Public Schools' data incident page told families and employees what the department understood about copied files and data categories. CMS's notice that it was responding to a data breach at a contractor shows how a federal program could be affected through contractor use. CalPERS's third-party breach notice shows the pension and supplier-chain version of the same issue. Each organization had to translate upstream evidence into a notice duty for its own population.

That translation can fail in subtle ways. A contractor may know a server was exploited but not yet know which customer files were copied. A data controller may know a file name but not the full population inside the file. A vendor may know a vulnerability was exploited but not see an on-premises customer's logs. A regulator may receive an initial notice before the affected-person count is stable. Every handoff creates uncertainty.

The repair standard should therefore require a notification evidence chain. For each sensitive transfer workflow, the operator should know who owns the data, who must be notified, which logs prove access, which files map to which populations, who reviews contents, and who approves final notice. The chain should be rehearsed before an incident. If the first time a public agency maps its MOVEit files to affected individuals is after mass exploitation, the transfer system was not governed as a high-risk boundary.

Product design can reduce the amount of residue

The strongest transfer-system repair is not only faster patching. It is less residue for attackers to steal. A managed file-transfer product can support this through product features and defaults: automatic file expiration, clear folder ownership, retention warnings, searchable audit trails, encryption controls, alerting on unusual download behavior, and administrative dashboards that show stale sensitive files. Operators still have to configure and use those features, but product design can make safer operation the easier path.

Progress's release notes for MOVEit Transfer 2023 and fixed issues in 2023 are patch and release records, not a full product-design audit. They still point to a broader expectation: after a major exploit, customers should look not only for the specific security update but for product changes that make future misuse less damaging. A transfer product should help customers understand what is still sitting in transfer space.

Operators also need residue metrics. How many files older than the business need remain in transfer folders? How many contain regulated data? How many are owned by former projects or departed employees? Which counterparties can still retrieve them? Which are encrypted at rest but readable through the application? Which have never been downloaded? Which have been downloaded unusually often? These are mundane questions, but they decide blast radius.

The Censys exposure analyses, MOVEit Transfer and MOVEit: an industry analysis, explain exposure from the outside. Residue metrics explain exposure from the inside. Both are needed. A server can be internet-facing and empty, which is still a patch risk but not a data-disclosure event. Another server can be patched late and contain years of sensitive files, which becomes far more serious. The outside scan and inside file inventory have to meet.

The accountable product-and-operator partnership is therefore straightforward. The vendor should provide controls that make stale sensitive files visible and reducible. The operator should set defaults that remove files promptly unless a documented need exists. Data controllers should prohibit transfer folders from becoming archives unless the retention and protection story is explicit. The goal is not only to prevent the next exploit, but to make the next exploit smaller.

Procurement should price evidence and cleanup

Organizations often buy managed transfer for reliability, security, and convenience. The MOVEit incident shows that procurement should also price evidence and cleanup. A buyer should ask whether the product can produce useful logs, whether those logs survive long enough, whether the vendor can support emergency forensics, whether retention controls are easy to enforce, and whether support can distinguish cloud-hosted and self-managed responsibilities in a crisis.

For public agencies, this is not paperwork. A school system, pension fund, health program, or contractor may have to notify hundreds of thousands of people. If the transfer system cannot quickly identify which files were accessed and what each file contained, the public notice process becomes slower and more expensive. The savings from a convenient transfer workflow can be overwhelmed by manual file review after a breach.

Contracts should state evidence duties. How fast must the operator notify the data controller after suspected exploitation? What logs and file lists must be delivered? Who pays for review? Who preserves evidence? Who communicates with the vendor? What happens if a contractor uses a transfer product without telling the data owner? Which retention rules apply to data after transfer? These contract terms are not legal ornament. They are the working instructions for the next crisis.

The UK FCA's MOVEit vulnerability statement asked regulated firms to understand direct and third-party exposure. That expectation should be built into procurement before a vulnerability appears. A firm cannot understand third-party exposure if its contracts and inventories do not reveal where files move.

The final procurement lesson is that trusted transfer is a service outcome, not a product label. A product can be designed for secure transfer while a customer uses it as unmanaged storage. A contractor can operate a patched instance while retaining too much data. A vendor can issue advisories while a buyer lacks inventory. The buyer should purchase and manage the whole evidence chain, because that is what affected people will need when the boundary fails.

Scale evidence should not flatten local duties

Broad public tallies helped readers understand the size of the MOVEit campaign, but they can also flatten the duties of individual operators. Emsisoft's public analysis compiled known organizations and affected individuals from public notices, filings, disclosures, and criminal claims. That scale signal is useful because it shows that the incident was not isolated. It should not become a substitute for local accountability.

Every organization in a tally still had its own questions to answer. Which server was affected? Was the instance managed internally or by a supplier? Which files were copied? Which data fields were inside them? Were the files still needed? Which regulator or contractual counterparty had to be told? Which affected individuals needed identity protection or other support? A global count cannot answer those local questions.

Scale evidence can also obscure time. Some organizations disclosed quickly; others needed months to review files and identify people. Delayed notice may reflect irresponsible slowness, genuine data-review complexity, supplier handoff delay, or legal caution. The public cannot assume one cause without evidence. But a mature operator can reduce that delay before the next incident by keeping file inventories, retention rules, and data-owner mappings current.

The strongest public reporting after a mass exploit should therefore combine two views. The first is the campaign view: vendor advisory, government alert, exploitation indicators, exposure measurement, and broad affected-population estimates. The second is the local view: specific operator chronology, data scope, notice basis, retention lessons, and remediation. MOVEit taught that both views are necessary. Campaign scale explains why the issue mattered; local evidence explains who was responsible for each affected person.

Board oversight should ask for boundary evidence

The board lesson from MOVEit is not that directors should become file-transfer engineers. It is that they should ask management for evidence about the boundaries that carry sensitive data. A board risk committee can ask simple, concrete questions: which managed transfer systems are internet-facing, who owns them, which sensitive data categories pass through them, how long files remain, which suppliers operate them, which logs prove access, and how quickly the organization can identify affected populations after a compromise. Those questions are ordinary governance questions once transfer systems are understood as trust boundaries.

The same questions should reach procurement and internal audit. Procurement can require vendors and managed-service providers to describe patch timing, emergency notification, log delivery, data deletion, and customer-specific evidence. Internal audit can sample whether transfer folders actually follow retention rules and whether system owners can produce file inventories. Security teams can test whether exposure scans, vulnerability alerts, and incident playbooks cover the transfer environment. Privacy teams can map which laws or contracts apply when files cross the boundary.

This evidence does not need to be theatrical. It can be a current inventory, a retention report, a recent tabletop exercise, a supplier-notification clause, an access-log sample, and a list of unresolved exceptions. What matters is that the organization can prove the boundary is governed before attackers test it. MOVEit showed that a trusted transfer product can become a shared exposure path very quickly. Boards should therefore treat trusted transfer as infrastructure, not clerical plumbing.

The final question for any organization using managed file transfer is whether it could answer an affected person's basic concern without weeks of reconstruction: was my data in the system, was it copied, why was it still there, who controlled it, who else received it, and what changed after the incident? If those answers require improvisation, the boundary is not yet accountable.

That local evidence is also what lets boards distinguish a completed patch task from a completed trust repair.