Trust is built into the engagement - not stapled on afterward.
OrbitWorks approaches security, data handling, delivery discipline, and documentation with the same seriousness we bring to architecture design. This page explains how.
How we think about secure delivery
Our delivery practice is built around a set of principles that apply regardless of engagement type, client environment, or project scope.
Least-necessary access
We do not request, retain, or operate with broader access to client systems, data, or environments than the engagement requires. Access is scoped to what is needed, documented when granted, and removed or reduced when the engagement phase concludes.
Clear system boundaries
Every engagement begins with an explicit understanding of what is in scope, what is not, and where the boundaries of our involvement sit. Ambiguity around scope is a security risk. We treat it as one.
Documentation discipline
Work product is documented as it is produced - not reconstructed afterward. Architecture decisions, design rationale, control recommendations, and implementation notes are captured in a form that is useful to the client, reviewable by auditors, and durable beyond the engagement.
Secure engineering practices
Where OrbitWorks has hands-on involvement in system design or implementation, we apply the same secure engineering discipline we recommend to clients - including control-aware design, secrets management, identity discipline, and delivery patterns that produce evidence rather than obscure it.
Operational review before handoff
Engagements do not close when work is functionally complete. They close when the client has the documentation, runbooks, and operational clarity needed to maintain what was built without us.
How client information is treated
Client information is handled with care proportional to its sensitivity and consistent with the obligations of the engagement.
- Confidentiality is treated as a baseline expectation, not a negotiated add-on
- Sensitive architecture details, regulated data, access credentials, and protected information should be shared only through agreed, secure channels - not through general communication tools or initial contact forms
- Information shared during an engagement is used to perform the engagement - it is not retained beyond operational need, shared with third parties for commercial purposes, or used to inform work for other clients
- Where subcontractors or specialist contributors are engaged, confidentiality obligations are extended to those parties consistent with the engagement agreement
For initial outreach, please use the Contact page and avoid including sensitive material. Secure information-sharing paths are established once an engagement is underway.
How standards inform our work
OrbitWorks uses recognized security and compliance frameworks to shape architecture decisions, delivery practices, and risk conversations - not as marketing decoration, but as a practical design input.
Our work is informed by NIST AI RMF, NIST SSDF (SP 800-218), NIST Zero Trust Architecture (SP 800-207), CIS Controls v8.1, ISO/IEC 27001:2022, GDPR privacy and security obligations, CMMC readiness practices aligned to NIST SP 800-171, and FIPS-aware cryptographic design where applicable.
We use precise language around framework alignment. We say aligned to, informed by, and supports readiness for - not “certified” or “compliant” - unless that status has been formally verified.
Full framework detail → Frameworks & AssuranceHow we approach AI risk
AI-enabled systems introduce security, privacy, governance, and operational questions that cannot be resolved by the model provider alone. They require explicit design choices at the architecture layer.
Bounded automation
Agentic and AI-driven systems should have clearly defined operational limits - what they can do, what requires human review, and what is explicitly out of scope for autonomous action.
Least-privilege access for agents
AI systems and automated workflows should not have broader access to systems, data, or APIs than the task requires. Tool-use boundaries and context controls are architecture decisions, not afterthoughts.
Observability and auditability
Actions taken by AI-enabled systems should be traceable. Logging, audit trails, and reviewable decision paths are part of the design - not optional enhancements.
Governance from the start
AI governance is not a policy document written after deployment. It is a set of design decisions made before the system is built. We treat it accordingly.
Our approach to secure agentic systems is informed by OWASP guidance on agentic application security, NIST AI RMF, and practical operational experience building and deploying governed AI systems.
Need to raise a security or privacy concern?
Security disclosures, privacy inquiries, and trust-related concerns are handled separately from general engagement inquiries.
If you have identified a potential security issue, have a question about how client data is handled, or need to raise a concern related to an active or past engagement, use the dedicated contact path below.
Security & privacy matters
Submit your security inquiry below.
Please do not include sensitive system details, credentials, or proof-of-concept exploit material in this initial message. Describe the nature of the concern and we will establish a secure communication path to continue the conversation.
For security disclosures, privacy inquiries, or urgent trust-related matters, you can also reach us directly at [email protected].
Trust should be easy to find and easy to understand.
If you have questions about how OrbitWorks handles security, privacy, or client information that are not addressed on this page, reach out directly. Transparency is part of the service.
Contact OrbitWorks