Minimize
Keep readable identity data out of the shared client record.
Security model
Privacy begins with architecture
The network assumes that every layer can make mistakes. Sensitive access therefore depends on more than a hidden button or a signed-in browser: identity handling, account state, agency membership, resident consent, record relationship, and database authorization each contribute a separate boundary.
Separate
Enforce agency, role, relationship, and consent boundaries in the data layer.
Verify
Require approved accounts and stronger authentication for partner access.
Record
Preserve attribution for important consent and referral actions.
Identity & data handling
Reduce the value of exposed data
Readable identity inputs used to recognize a resident are handled by a protected server workflow. That workflow derives a consistent, one-way pseudonymous identifier; the readable inputs are not written into the shared client record. This allows an authorized match without turning the network into a central list of names and birth dates.
- The public service directory is separated from authenticated partner records.
- Raw matching values and operational lookup records are not exposed through the normal partner data interface.
- External email notifications remain generic and send staff back to the signed-in portal for client-linked context.
- Data exports neutralize spreadsheet cells that could otherwise be interpreted as formulas when a file is opened.
Authorization
Access is decided near the data
Database row and column controls are the primary enforcement boundary. A page cannot grant access merely because it renders a link. Each sensitive request is evaluated against the signed-in user and the record being requested.
- Agency boundary
- Membership limits which agency records a person can act on.
- Role boundary
- Administrative actions require the appropriate scoped role.
- Relationship boundary
- Client access depends on a legitimate service relationship.
- Consent boundary
- Sharing scope can further narrow history, needs, or referrals.
The checks are designed to fail closed: when the system cannot safely verify an account or stronger-authentication state, protected client information is not loaded.
Accounts & authentication
A login is necessary, but not sufficient
- Partner agencies require network approval before protected network access is available.
- Team invitations are bound to the intended recipient and do not silently become open membership links.
- Approved agency staff and network administrators must complete authenticator-based two-factor verification before the protected portal opens.
- Stronger-authentication requirements are enforced for sensitive database actions, not only by the screen-level gate.
- Password recovery requires evidence from the recovery flow, expires quickly, and attempts to revoke existing sessions after a successful reset.
Consent & accountability
Sensitive changes leave context behind
Missing or expired consent does not become broad sharing. Sharing can be scoped by type and by agency, while access still remains subject to the other authorization boundaries described above.
Consent changes, referral status changes, and assignments preserve timestamps and actor attribution. Important referral origin fields are protected from later rewriting, which helps the record remain meaningful during review. Auditability supports investigation and accountability; it does not give every user permission to read every audit record.
Application & infrastructure
Protection continues outside the database
- Browser-to-service traffic uses encrypted HTTPS connections.
- Application responses prevent the portal from being embedded in another site, reducing clickjacking risk.
- Server-only credentials and identity-processing secrets are kept out of browser bundles and public pages.
- Public directory queries return a deliberately limited organization profile rather than internal approval, ownership, or account metadata.
- Automated tests cover high-risk boundaries such as tenant isolation, consent, authentication, exports, notifications, and security response headers.
Disclosure boundary
What this page intentionally does not publish
Public transparency should help partners assess the model without becoming an attacker's field guide. We do not publish secret material, environment or vendor configuration, internal identifiers, detection thresholds, detailed network topology, backup schedules, private test vectors, vulnerability findings, or incident-response playbooks. Qualified reviewers can request a more focused conversation through the security contact below.
Found something we should know about?
Please report suspected security or privacy issues privately. Include enough detail for us to reproduce the concern, but do not access or include anyone else's information.
security@kzoocare.org