Security and engineering practices

1. Security in the development lifecycle

Security is built into the way we work, not added after the fact:

• We model threats during the architecture phase, so the trade-offs are written down before any code exists.
• Every change is reviewed by another engineer, and nobody commits directly to protected branches.
• Our pipelines scan dependencies and look for exposed secrets. A build fails when a finding is serious.
• Automated tests decide whether a release goes out, so the risk sits with the pipeline and not with whoever is on call that day.

2. Access control

• Named accounts only. Engineers never share credentials.
• Access is limited to the project, granted on a minimum-necessary basis and removed when the project ends or the person leaves it.
• Multi-factor authentication on every system that supports it.
• Production access is restricted to those who need it, and every access is logged.

3. Data handling

• Data is encrypted in transit (TLS) and at rest, with the platform's managed keys unless you require something different.
• Secrets live in a managed secret store. They are never kept in source control or in configuration files.
• Production data is not copied to developers' machines. When realistic test data is needed, we mask it or generate synthetic data.
• We work inside environments you control whenever you prefer that arrangement.

4. HIPAA projects

When a project involves Protected Health Information, Trivo acts as a Business Associate:

• A Business Associate Agreement is signed before anyone has access to PHI.
• We apply the administrative, physical and technical safeguards of the HIPAA Security Rule.
• Access follows the minimum-necessary rule, is granted to named individuals and leaves an audit trail.
• PHI is encrypted in transit and at rest, and stays inside the environments agreed with you.
• If a breach occurs, we notify you without unreasonable delay and support you in meeting your own obligations.
• Subcontractors are bound in writing to equivalent terms.

5. Operations and resilience

• Infrastructure is defined as code, so environments can be reproduced and every change can be reviewed.
• Monitoring and alerts are set up as part of the delivery, not bolted on later.
• Backup and restore procedures are tested for real, not only configured.
• Changes are released in small steps, with a rollback path defined before each deployment.

6. People

• Everyone with access to client systems is bound by confidentiality, including subcontractors.
• Background checks are carried out when a project or a regulation calls for them.
• Access is reviewed whenever someone joins or leaves a project.

7. What we put in writing

Before a project starts, we will gladly complete your security questionnaire, sign your BAA or DPA, agree to your access and data residency requirements and take your security team through anything described here.

If any of this falls short of what you need, tell us. That conversation is far better now than after a contract is signed.

8. Reporting a concern

If you believe you have found a vulnerability in something we operate, write to hi@trivoandco.com. Please include enough detail for us to reproduce it. We will confirm receipt, investigate and keep you informed, and we will not take action against research carried out in good faith.