# Asama AI's SOC 2 journey: building trust into the architecture > How Asama AI prepared for a SOC 2 Type I audit in five weeks, how the Trust Services Criteria shaped its design, and what a CISO checks before an AI agent acts. - URL: https://blog.asama.ai/blog/asama-ais-compliance-journey-building-trust-through-architecture/ - Author: Jain Johny - Published: 2025-11-13 - Tags: Company **Asama AI has completed its SOC 2 Type I audit.** [SOC 2](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services) is an independent auditor's report on how a company's controls meet the AICPA's Trust Services Criteria: security, which every report covers, and any of availability, processing integrity, confidentiality and privacy. Asama's report covers all five. A Type I report assesses how the controls are designed at a point in time; a Type II report also tests whether they operate effectively over a period, typically three to twelve months. For a CISO, the report is where the decision starts on whether an AI agent can work near production. At Asama AI, we’ve always believed that infrastructure shouldn’t just be fast and scalable; it must be inherently secure. As an AI Infrastructure Engineer, Asama is designed not just to monitor but [to remediate](https://blog.asama.ai/blog/article-03-asama-what-happens-when-the-loop-ends). To do that, it has to operate in some of our customers’ most sensitive environments. The audit wasn’t just a “check-the-box” exercise for us. It was a rigorous journey to validate the security foundations we’ve built since day one. ## Trust as a design constraint For many startups, compliance is seen as a hurdle, a mountain of paperwork to be tackled only when a deal is on the line. At Asama, we took a different path: trust built into the architecture. We believe that for an AI Infrastructure Engineer to be effective, trust must be a primary design constraint, not an afterthought. We designed our system for "auditability by default", with the five Trust Services Criteria as design requirements: - **Security**: protecting our systems against unauthorised access and potential vulnerabilities through continuous monitoring and automated safeguards. - **Availability**: keeping our platform operational and accessible when your infrastructure needs it most. - **Processing integrity**: checking that our AI agents complete their tasks accurately, on time and within authorised parameters. - **Confidentiality**: keeping your sensitive organisational data protected with rigorous access controls and secret management. - **Privacy**: handling personal and sensitive information under strict practices, so it is collected, used and retained responsibly. By treating these as architectural requirements rather than administrative layers, we keep trust a working part of our technical stack. ## What a CISO checks before an AI agent touches production When an organisation adopts Asama AI, two evaluations run in parallel. Infrastructure teams assess the platform's functionality and non-functional requirements (NFRs); the CISO's team looks deeper at security and compliance. For a CISO, evaluating an AI tool is an exercise in risk management. They are looking for a partner that won’t increase their attack surface or introduce vulnerabilities into their production environments. SOC 2 is the cornerstone of that evaluation: it gives them independent evidence about the controls around our platform. Here is what we believe matters to a CISO's team: - **Independent evidence, not a promise**: an outside auditor has examined our controls, so your security team can read the report instead of taking our word for it. - **Lower breach risk**: the controls the audit examines, from access reviews to change management, reduce the risk of unauthorised access or of an agent acting outside its scope. - **Shorter security reviews**: the report answers much of a vendor security questionnaire up front, which speeds up enterprise onboarding. - **A common procurement bar**: many regulated buyers ask for a SOC 2 report before a vendor gets near production systems, from financial services to teams guarding proprietary IP. - **Governance that keeps running**: the audit ties our protocols to written policies that we review and improve, which is what separates an enterprise product from a tool. ## Five weeks from scope to mock audit While the mindset of trust was built in from the start, the formal execution was a concentrated five-week sprint. We followed an eight-step preparation roadmap, using automation to keep pace: - **Define the Audit Scope**: We clearly identified which business units and systems were relevant to the audit. - **Select a Qualified Auditor:** We partnered with an experienced firm that understands cloud-native AI infrastructure. - **Conduct a Gap Analysis:** We identified where our current controls fell short of SOC 2 requirements. - **Develop and Document Policies:** We formalised our internal processes into clear, actionable security policies. - **Implement Necessary Controls:** We closed identified gaps by strengthening technical safeguards. - **Employee Training and Awareness:** We ensured every team member understood their role in security. - **Gather Evidence of Compliance:** We utilised automation to collect logs and configurations. - **Conduct a Readiness Assessment:** We ran a “mock audit” to ensure there were no surprises. ## What we learned The journey taught us that trust isn’t a badge you earn; it’s a system property you maintain. - **Automation is the Foundation**: Manual evidence collection is the enemy of speed. Automated compliance allowed our engineers to stay focused on building while the system proved its own integrity. - **Culture Over Policy**: A policy is just a document unless the team lives it. Every engineer at Asama understands that security is a core feature, not a side-hustle. - **Design for Trust Early**: It is far harder to bolt trust onto a legacy system than to [build it into a young, agile architecture](https://blog.asama.ai/blog/unpopular-opinion---do-not-build-what-customers-want). ## What comes after SOC 2 Our engineering team is already working on the next milestones. Much of the control work behind SOC 2 carries over to ISO 27001, and some of it to GDPR. We are using that momentum to work towards: - **GDPR**: Strengthening data privacy guarantees for our European partners. - **ISO 27001**: Adopting the international gold standard for information security management. - **NIST AI RMF**: Aligning our agentic AI workflows with NIST's AI Risk Management Framework, so we remain the most responsible teammate in your stack. Trust is earned in drops and lost in buckets. At Asama AI, we are committed to filling that bucket, one architectural decision at a time. **Update, October 2026.** Asama's fleet visibility is generally available, and detection built on it has been validated; investigation and remediation are expanding. In October 2026, Asama completed its SOC 2 Type II audit, which tests the same controls in operation over a period of months; you can request the report at [trust.asama.ai](https://trust.asama.ai). Its platform also undergoes regular manual penetration testing. The architecture follows the same idea: the SaaS plans and never touches your infrastructure, an executor on your premises accepts only signed, in-scope manifests, and BMC credentials stay in your own Vault. On day one, your engineers approve every plan. To take your security team through it, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.