Private household records

Wholekin

Trust and security

Why households can trust us with sensitive records.

Wholekin is built for private household operations, where trust is part of the product itself. Our controls reflect the standards serious customers expect in ISO 27001 and SOC 2 style reviews, with clear attention to access control, protected infrastructure, secure authentication, disciplined change management, and data handling.

We design for explicit control boundaries and professional operational discipline.
We use managed security building blocks that align with industry best practices.
We treat code quality, validation, and change review as part of the security posture.
We are building toward the control maturity serious buyers expect in ISO 27001 and SOC 2 conversations.
Trust is engineered, not implied
We build the platform with the access, change, infrastructure, and data-protection controls sophisticated buyers expect to see documented, reviewed, and operationalized in professional software organizations.
Identity, authorization, and session handling are treated as control systems, not convenience features.
Production infrastructure is built around managed AWS boundaries for transport, secrets, logging, and private data services.
Change quality is enforced through CI, static analysis, testing, and image scanning before deployments move forward.

Current controls

High-level controls behind the current implementation

These are the control areas that matter most when evaluating whether a product can responsibly hold private household data.

Encryption and protected data handling
Sensitive household records deserve strong transport security, encrypted storage, and disciplined secret handling. We use proven AWS security services and established engineering practices to protect critical data throughout the platform.
  • Public traffic is served exclusively over HTTPS.

  • Certificates are managed through AWS Certificate Manager for the public application surface.

  • Application secrets are managed through AWS Secrets Manager.

  • Storage resources in the stack are configured with encryption and blocked public access by default.

Strong authentication and session protection
We treat authentication and session handling as core platform controls. Identity is delegated to a dedicated provider, tokens are validated on the server side, and browser sessions are handled through protected, signed cookies.
  • Authentication is delegated to Auth0.

  • The backend validates issuer, audience, and signing material before accepting tokens.

  • Session cookies are signed, HttpOnly, and marked Secure in production.

  • Refresh handling remains inside the SSR session flow and follows modern browser security practices.

Secure identity and access management
Trust depends on precise access boundaries. Access in Wholekin is family-scoped, role-based, and policy-driven so visibility stays explicit as households, staff, and advisors change over time.
  • Authorization decisions are backed by Cedar.

  • Policies and schema are validated at startup so broken authorization definitions fail before serving requests.

  • Permissions are expressed explicitly for create, list, read, update, and delete operations.

  • Critical business safeguards still sit behind service-level protections, including owner-protection rules.

Validation and data integrity
A trustworthy record system protects against malformed input, accidental drift, and unsafe changes. We use validation and quality gates so both records and code are held to a high standard before they are accepted.
  • Core entity operations rely on validated request models.

  • Domain-specific validators protect important record rules such as relationship structure and phone formatting.

  • Frontend changes must pass formatting, typing, linting, and build checks in CI.

Cloud architecture and infrastructure boundaries
The production environment is deployed on AWS with clear network boundaries, managed certificates, secure secret storage, centralized logging, and a private database footprint. Our infrastructure follows the patterns serious software teams rely on for dependable operations.
  • The primary database is not publicly exposed and runs in private isolated subnets.

  • Database credentials are generated and stored in managed secret storage.

  • Operational logging and container visibility are enabled for the running environment.

  • Backups and database log export are part of the deployed stack.

Quality, change control, and vulnerability reduction
Trust is also about how changes are introduced. We use CI quality gates, static analysis, testing, and image scanning to reduce avoidable defects and security regressions before code moves toward production.
  • Frontend CI requires formatting, typechecking, linting, and a production build.

  • Backend CI runs formatting, static analysis, tests, and strict compilation checks.

  • Container repositories are configured for image scanning on push.

  • Static analysis is built into the backend delivery pipeline.

About Cedar and access control
Our authorization model is family-scoped and role-based, with decisions evaluated through Cedar. In practice that means access is tied to explicit roles and resources with clear visibility boundaries.

Cedar gives us a rigorous foundation for secure identity and access management. That matters in a household system where principals, relatives, staff, and advisors should not all inherit the same view of the record.

We pair policy-driven access control with service-level safeguards for critical invariants, such as owner protection. That combination reflects the control discipline expected in mature enterprise software.

Professional control posture
Wholekin is developed to demonstrate trust operationally through clear access boundaries, controlled infrastructure, secure identity flows, disciplined change management, and engineering standards aligned with industry best practices.

Continue your review

See how the product model and the trust model fit together.

If you are evaluating Wholekin for a principal household, advisor workflow, or family office setup, the next useful step is usually to review the feature model and the operating use cases alongside the trust controls.