Trust is built into the system.

01 / Security architecture

Controls follow the system boundary.

Start with the information, the actors, and the consequences of failure. Threat modeling and architecture review should identify the trust boundaries, responsibilities, and controls appropriate to the project.

• Least-privilege access between components and environments.
• Server-side authorization and validated inputs at application boundaries.
• Managed secrets, dependency review, and a defined remediation process.

02 / Identity & access

The right access, for a defined purpose.

Identity should fit the institution’s operating model. Integration with an existing identity provider can support single sign-on and consistent account lifecycle management. Roles and permissions must reflect actual responsibilities.

• Explicit permissions for users, administrators, and service accounts.
• Separation of preparation, review, and approval where the workflow requires it.
• Documented provisioning, access review, and offboarding responsibilities.

03 / Data protection

Know what is held, and where it goes.

Data protection starts with classification and minimization. Agree what a system needs to collect, how it is transmitted and stored, who can access it, and when it should be removed.

• Encryption in transit and at rest using appropriate platform capabilities.
• Environment separation and controlled handling of test data.
• Retention, deletion, and vendor data handling defined for the implementation.

04 / Auditability

A decision should leave a useful record.

Activity history should explain meaningful actions, changes, and approvals. Audit events need enough context to reconstruct a decision without turning general application logs into a second store of sensitive records.

• Record actor, action, time, and relevant record references.
• Define access to audit history and retention according to the institution’s requirements.
• Distinguish business audit events from diagnostic and operational logs.

05 / AI governance

Assistance with clear boundaries.

An AI output is an input to a decision, not evidence that the decision is correct. The implementation should define sources, permitted actions, review requirements, and evaluation criteria before expanding automation.

• Permission-aware retrieval and source references where applicable.
• Human approval for consequential actions and a safe path when a system is uncertain.
• Representative evaluations, observable behavior, and model/provider data terms reviewed for the use case.

06 / Accessibility

Usability is a public requirement.

WCAG 2.2 AA is our design target. Semantic structure, keyboard operation, clear language, visible focus, and understandable form errors are part of the design process. Automated checks are supplemented by manual review.

• This website uses semantic HTML, a skip link, labeled controls, and reduced-motion support.
• Navigation and primary content remain available without JavaScript.
• A project’s testing scope and required accessibility documentation should be agreed explicitly. No certification or ACR is implied.

07 / Reliability & maintenance

Plan for the life of the system.

A maintainable system needs a repeatable release process, observable operation, and named responsibilities. Availability, restoration, and support expectations should be agreed in terms the institution can verify.

• Automated checks, controlled releases, and rollback procedures.
• Appropriate alerts, diagnostic logging, and recovery testing.
• Documented ownership of dependency updates, support, and routine maintenance.

08 / Data ownership & deployment

Keep the institution’s options open.

Ownership and access rights belong in the contract. Documented schemas and practical export formats help an institution retain use of its information. Deployment choices should follow data classification, operational needs, and procurement requirements.

• Define supported exports and the process for retrieving institutional data.
• Evaluate cloud, institution-managed, or restricted environments against actual requirements.
• A hosting platform’s certifications do not automatically certify an application or authorize a deployment.

The public website

A small, deliberate footprint.

This site delivers pre-rendered pages with local fonts and original web graphics. It does not add analytics, advertising trackers, third-party embeds, or browser storage. Security headers and a restrictive content policy are part of its Cloudflare deployment configuration.

The contact form prepares an email draft in your own mail application. It does not submit the entered fields to a website server. A downloadable text brief is also available.

Security or accessibility concerns

Contact hello@capzero.com with the affected page and a short description. Please avoid including sensitive records or credentials.