Private household records

Family Assets

Trust and security

Why households can trust us with sensitive records.

Family Assets is built for private household operations, where trust is part of the product itself. Our controls are designed around the standard 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 instead of informal access and tribal knowledge.
We use managed security building blocks where they are stronger than custom implementation.
We treat code quality, validation, and change review as part of the security posture.
We are building toward the kind of control maturity serious buyers expect in ISO 27001 and SOC 2 conversations.
Trust is engineered, not implied
We build the platform with the kinds of access, change, infrastructure, and data-protection controls that 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 protected transport, encrypted storage layers, and disciplined secret handling. We use managed AWS capabilities to reduce the chance that critical data is exposed through weak defaults or ad hoc handling.

Public traffic is forced onto HTTPS rather than left to optional transport security.

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

Application secrets are handled through AWS Secrets Manager instead of being embedded in deployable artifacts.

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

Strong authentication and session protection
We treat authentication as a control surface, not just a login screen. Identity is delegated to a dedicated provider, tokens are validated on the server side, and browser sessions are handled with signed, protected cookies rather than casual client-side storage.

Authentication is delegated to Auth0 rather than implemented as a custom identity system.

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

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

Refresh handling stays in the SSR session flow instead of relying on browser storage APIs for long-lived tokens.

Secure identity and access management
Trust depends on keeping the right people in the system without giving everyone the same visibility. Access in Family Assets is family-scoped, role-based, and policy-driven so control remains explicit as households, staff, and advisors change over time.

Authorization decisions are backed by Cedar rather than scattered one-off checks.

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 has to protect against malformed input, accidental drift, and unsafe changes. We use validation and quality gates so records and code both face scrutiny before they are accepted.

Core entity operations rely on validated request models rather than permissive free-form payloads.

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
We prefer well-understood managed infrastructure boundaries over bespoke operational complexity. The production environment is deployed on AWS with separate network boundaries, managed certificates, secret storage, logging, and a private database footprint.

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 part of the backend build rather than an afterthought.

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 rather than broad, accidental visibility.

Cedar gives us a more rigorous foundation for secure identity and access management than scattered, ad hoc permission checks. 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 is closer to the control discipline expected in mature enterprise software than a simple role toggle model.

Professional control posture
Family Assets is developed with the expectation that trust must be demonstrated operationally. That means clear access boundaries, controlled infrastructure, secure identity flows, disciplined change management, and engineering standards designed to support long-term confidence in how sensitive records are handled.

Continue your review

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

If you are evaluating Family Assets 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.

Review platform featuresSee the use cases