Access Requests Where the Answer Is on Video

What you can do together

• Redact video and audio attached to an access request at volume, instead of an analyst working clip by clip against a deadline.
• Keep the request identifier on every item so a released clip is traceable to its request and its decisions.
• Hold a decision record per redaction, available if a release is reviewed.
• Run the whole of it inside a deployment that satisfies the institution's residency requirement.

How it connects

Media attached to a request would come into Redactor with the request identifier carried as an attribute, so every item is traceable to its request. Redaction runs at volume with each decision recorded, which is what an institution relies on if a release is reviewed.

The return path needs stating precisely. Documented export destinations are AWS storage and SharePoint, so a releasable file lands in a destination the institution controls rather than being written into the ATIPXpress case directly. A webhook would notify on completion, and wiring that into the case record is the integration an engagement scopes against the ATIPXpress API.

Two things matter more here than in the US equivalent. Data residency is usually a requirement rather than a preference, so the deployment is chosen for where processing and storage sit, and the platform runs as dedicated SaaS, in the institution's own cloud subscription, on its own servers or air-gapped. And the exemptions applied under Canadian access and privacy legislation differ from the US ones, so an engagement settles how exemption categories map onto redaction reasons rather than assuming a FOIA configuration transfers.