ComplianceReading time: 9 minutes

ISO 27001 and SOC 2 Type II for AI-Driven ServiceNow Development

Where SnowCoder sits against ISO 27001:2022 and SOC 2 Type II today, the controls already in place, and the roadmap through to certification.

The Honest Position

It is tempting for any AI vendor to wave a compliance badge before the audit has actually completed. SnowCoder does not. The honest position, which any procurement team can verify against the artifacts on the security page, is the following:

  • ISO 27001:2022 - 78% control alignment, 73 of the 93 Annex A controls implemented and evidenced, ISMS in progress, target certification Q4 2026
  • SOC 2 Type II - in progress, target completion Q3 2026
  • GDPR - compliant, with DPA available at contract signature
  • PCI DSS - compliant via Stripe for the payment surface, no card data touches SnowCoder systems
  • NIST 800-63B - compliant for identity assurance
  • OWASP Top 10 - all categories addressed in the SDLC and verified in security testing

This article walks through what the 78% Annex A alignment actually covers, which controls remain in flight, and how SOC 2 evidence is being gathered in parallel.

ISO 27001:2022 Annex A - What Is Covered

The 2022 revision of ISO 27001 consolidated Annex A to 93 controls grouped under four themes: Organisational (A.5), People (A.6), Physical (A.7), and Technological (A.8). The 73 controls already implemented at SnowCoder cluster in the technological and organisational themes. The mapping below names the controls most relevant to AI-driven ServiceNow development.

Annex A Control          | SnowCoder Implementation
-------------------------+----------------------------------
A.5.10 Acceptable use    | Acceptable Use Policy enforced via
                         | tenant T&Cs and product guardrails
-------------------------+----------------------------------
A.5.14 Information       | TLS 1.3 for all transfers; signed
   transfer              | OAuth tokens for inter-service
-------------------------+----------------------------------
A.5.23 Cloud services    | AWS as primary IaaS; customer-
                         | chosen region residency on Enterprise+ (and Enterprise)
-------------------------+----------------------------------
A.5.30 ICT readiness     | Documented RTO/RPO with EU
                         | cross-region backup
-------------------------+----------------------------------
A.6.3 Awareness training | Annual security training for all
                         | engineering staff
-------------------------+----------------------------------
A.8.1 User endpoint      | MDM enforced on engineering laptops
   devices               |
-------------------------+----------------------------------
A.8.2 Privileged access  | JIT elevation with audit trail
-------------------------+----------------------------------
A.8.3 Access restriction | Per-tenant isolation enforced at
                         | storage and key layer
-------------------------+----------------------------------
A.8.5 Secure auth        | OAuth 2.1 + PKCE, refresh-token
                         | rotation, replay-attack detection
-------------------------+----------------------------------
A.8.9 Configuration mgmt | Infrastructure-as-code, version
                         | controlled, peer reviewed
-------------------------+----------------------------------
A.8.10 Information       | AES-256-GCM at rest with per-record
   deletion              | salt + PBKDF2 (100k iterations)
-------------------------+----------------------------------
A.8.16 Monitoring        | Centralised log aggregation with
                         | tamper-evident retention
-------------------------+----------------------------------
A.8.23 Web filtering     | Egress allow-list on production
-------------------------+----------------------------------
A.8.24 Cryptography      | KMS-backed keys, documented key
                         | rotation cadence
-------------------------+----------------------------------
A.8.25 Secure SDLC       | Threat-modelled designs, SAST,
                         | DAST, dependency scanning
-------------------------+----------------------------------
A.8.28 Secure coding     | OWASP Top 10 verified in build

The 20 controls outstanding are largely in the People and Organisational themes - formal risk assessment register cadence, supplier review documentation, and incident playbook tabletop exercises - all of which are being finalised as part of the ISMS roll-out. None of the gaps are technical.

The ISMS Build-Out: What "In Progress" Means

An Information Security Management System is not a single document. It is a set of policies, processes, and evidence streams that together demonstrate continuous control. The SnowCoder ISMS build-out is following the standard staged approach.

  • Stage 0 - Scope: Complete. The ISMS scope covers all SnowCoder products (Yeti AI Chat, Yeti Drive, Yeti Build Agent, Instance Audit, MSP Agents) and the supporting cloud infrastructure
  • Stage 1 - Policy library: Complete. 14 ISMS policies are published internally and version-controlled
  • Stage 2 - Risk treatment: In progress. The Statement of Applicability is in final review
  • Stage 3 - Stage 1 audit: Scheduled. Readiness review with the certification body
  • Stage 4 - Stage 2 audit: Q4 2026. Full certification audit

Customers under NDA can request the current Statement of Applicability and the ISMS scope statement directly from the SnowCoder security team.

SOC 2 Type II - Where The Evidence Comes From

SOC 2 Type II is fundamentally an evidence exercise. Unlike Type I, which captures controls at a point in time, Type II requires evidence of those controls operating across a defined observation window, typically six to twelve months.

SnowCoder is currently in the observation window. The evidence streams being collected map to the five Trust Service Criteria:

Trust Service       | Primary Evidence Source
Criterion           |
--------------------+---------------------------------------
Security            | Vulnerability scan reports, pen test
                    | reports, access review logs, change
                    | management records
--------------------+---------------------------------------
Availability        | Uptime metrics, incident timelines,
                    | RTO/RPO test results, capacity logs
--------------------+---------------------------------------
Processing          | Code review records, deployment
   Integrity        | pipeline logs, anomaly detection
                    | reports
--------------------+---------------------------------------
Confidentiality     | Encryption configuration, key rotation
                    | logs, data classification matrix
--------------------+---------------------------------------
Privacy             | DPA execution log, SAR fulfilment
   (where applied)  | records, retention policy evidence

The target completion date for the Type II report is Q3 2026. The bridge letter approach will be used to cover any gap between report periods.

Why AI Adds Specific Control Considerations

Standard ISO and SOC frameworks were not written with foundation models in mind. AI-specific control considerations have to be layered on top. SnowCoder bakes the following into the SDLC:

  • Model provenance: Every model in production is logged against the version, the foundation model family, and any fine-tuning data sources
  • Prompt injection defence: Input sanitisation and structured tool calling reduce the risk of malicious prompts coercing the model into leaking state
  • Output validation: Generated code passes through syntax, ServiceNow, security, and performance validation before it reaches the user
  • Destructive-change confirmation: No deletion or bulk update is executed without explicit user approval, regardless of model output
  • Token budget as a hard stop: A documented spend ceiling per tenant prevents runaway agent loops
  • Two-lane separation: Humans operate in Yeti, agents operate on schedule, with no shared interactive surface

These six controls are documented as the AI-specific extension to the ISMS and form the basis of the AI risk register entries.

What This Means For Your Procurement Pack

If you are putting together a procurement pack for SnowCoder, the following artifacts are available today:

  • DPA template, executable at contract signature
  • Security overview document (the public summary on the security page)
  • ISO 27001 Annex A control alignment matrix (under NDA)
  • Statement of Applicability draft (under NDA)
  • Pen test summary letter from the most recent annual test
  • Sub-processor list with EU residency annotation for Enterprise plans

The Enterprise security page also documents the four commercial safeguards that procurement teams care about most: per-tenant isolation, two-lane human-agent separation, destructive-change confirmation, and the token budget hard stop. These are commercial commitments, not aspirational targets.

Related reading

Need the security pack?

The DPA, sub-processor list, and Annex A control mapping are available on request. Talk to Sales to start the diligence conversation.