Security & Engineering Practices
How we build, what we protect, and what we will put in writing
Last updated: July 2026
Most of what makes software safe is decided long before a security review. These are the practices we bring to every engagement, and we are happy to walk through any of them in detail before you commit to anything.
Security inside the SDLC
Not a gate at the end. Threat modelling and review sit in the same flow as the build.
Least privilege by default
Named access, scoped to the engagement, revoked when it ends.
HIPAA-ready delivery
Business Associate Agreements, minimum-necessary access, and safeguards under the Security Rule.
1. Security in the development lifecycle
Security is part of how the work is done, not a review at the end:
- Threat modelling during architecture, so the trade-offs are on the record before code exists.
- Peer review on every change, with no direct commits to protected branches.
- Dependency and secret scanning in continuous integration; builds fail on findings that matter.
- Automated tests as the gate for release, so risk is carried by the pipeline rather than by whoever is on call.
2. Access control
- Named accounts only, with no shared credentials between engineers.
- Access scoped to the engagement, granted on the minimum-necessary principle, and revoked when the engagement or the person’s role in it ends.
- Multi-factor authentication on everything that supports it.
- Production access limited to those who need it, and logged.
3. Data handling
- Encryption in transit (TLS) and at rest, using the platform’s managed keys unless the client requires otherwise.
- Secrets held in a managed secret store, never in source control or configuration files.
- Production data is not copied to developer machines. Where realistic test data is needed, it is masked or synthetic.
- We work inside client-controlled environments whenever the client prefers that arrangement.
4. HIPAA engagements
Where an engagement involves Protected Health Information, ZIONN operates as a Business Associate:
- A Business Associate Agreement is executed before any access to PHI.
- Administrative, physical, and technical safeguards under the HIPAA Security Rule.
- Minimum-necessary access, by named individual, with an audit trail.
- PHI encrypted in transit and at rest, and kept inside environments agreed with the client.
- Breach notification without unreasonable delay, and cooperation with the client’s own obligations.
- Subcontractors bound by equivalent written terms.
5. Operations and resilience
- Infrastructure defined as code, so environments are reproducible and changes are reviewable.
- Monitoring and alerting configured as part of delivery, not added afterwards.
- Backup and restore procedures that are actually tested, not merely configured.
- Changes released incrementally, with a rollback path defined before deployment.
6. People
- Confidentiality obligations for everyone with client access, including subcontractors.
- Background checks where an engagement or regulation requires them.
- Access reviewed when someone joins or leaves an engagement.
7. What we will put in writing
Before an engagement starts, we are glad to complete your security questionnaire, sign your BAA or DPA, agree to your access and residency requirements, and walk your security team through any of the above.
If something here does not meet your bar, tell us. It is a better conversation to have now than after a contract is signed.
8. Reporting a concern
If you believe you have found a vulnerability in something we run, write to security@zionn.io. Please include enough detail to reproduce it. We will acknowledge, investigate, and keep you informed, and we will not pursue action against good-faith research.