01
Public requests, partner accounts, and admin tools are separated so the same person does not automatically have the same level of access everywhere.
Public summary
Security overview
A high-level summary of the system, sign-in protections, and access controls for an organization’s first review.
- Updated
- August 30, 2026
- Scope
- Public summary
- Escalation
- Formal follow-up available
Current control position
Blacklight separates public, partner, and administrative authority. Partner access is server-scoped to one organization and its assigned role or locations, while the highest-risk actions require a current session, recent authenticator verification, and an auditable reason.
Security overview · Current public evidence boundary
Current safeguards
What Blacklight currently does
These statements describe implemented controls and their limits in plain language. They are not a certification, legal opinion, or substitute for an institution-specific contract requirement.
02
Sensitive actions such as billing changes, privacy handling, partner-access changes, and high-risk admin actions sit behind stronger authentication requirements and auditability.
03
The public request form stays simple, while privileged controls are limited to signed-in staff and authorized partner users.
04
Production migrations and runtime releases use reviewed source, exact-target checks, durable release controls, health verification, and recorded rollback inventory rather than an untracked dashboard-only deployment path.
05
Blacklight also maintains an automated accessibility baseline across key public review surfaces and preview-safe portal shells, while keeping the trust claim itself narrower than a formal accessibility certification.
Next review path
Open the next document only if the review actually needs more
Start with this summary. Then move into the packet, appendix, or formal follow-up only when the reviewer needs a broader or more formal response. Move into partner review when the next useful step is rollout fit, launch scope, and trust review together.
Use the packet when the team needs one concise review document.
Best for a first review share before deeper follow-up starts.
Open trust packetUse the appendix when the reviewer needs deeper technical detail.
Best for retention periods, provider handling, protected tokens, and detailed access controls.
Open technical appendixStart the partner request when trust diligence has become a real rollout decision.
Best when the review now needs program fit, launch plans, and trust questions considered together.
Start partner reviewRequest formal trust follow-up when the public materials are no longer enough.
Best for questionnaire packets, procurement follow-up, or trust-specific requests that need a formal response.
Request security follow-up