Framework · ISO 42001
ISO 42001 — AI management system.
ISO/IEC 42001 covers the AI management system — the AIMS controls that govern every model that pulls a lever. This page walks the framework, the controls in scope, and how to request the latest report.
ISO/IEC 42001 is the framework that audits Helmsway's AI control tower — the system that decides which model pulls which lever, on which signal, at which corridor. It tells a security reviewer that AI governance isn't a policy document behind an NDA; it is the same controls the operational platforms run, with named owners, residual-risk tiers and quarterly review windows.
Internal audit + AIMS review
Audit cadence · AIMS
AIMS review window — quarterly AI risk-register review against the assessment row the auditor pulls at the next surveillance window, plus a six-month internal audit that diffs the AI risk register line-by-line against the AIMS controls in scope below and the Helmsway levers they govern.
Statement of applicability — AIMS
Every AIMS control family, declared.
The AIMS SoA booklet names every Annex A control family applicable to the AI system — applicable, not-applicable or justified-exclusion — with a one-line rationale per row. The auditor diffs the named rows against the next surveillance find; the prose is the framing, the rows are the test.
- AIMS — IN SCOPE
32
AIMS controls marked applicable across the AI control tower — policy, roles, risk assessment, impact categories, data governance and human oversight, scoped to every model that pulls a Helmsway lever.
- AIMS — OUT OF SCOPE
2
AIMS controls marked not applicable — Annex A families that don't intersect the AI control tower (e.g. supplier-security concerns owned by the ISMS), signed off at the most recent AIMS review window with a one-line rationale per row.
- AIMS — EXCLUDED
3
AIMS controls excluded with a written justification — surfaced row-by-row on the SoA so the auditor reads the rationale without ambiguity.
- A.6.2.5 AI system acceptance criteria — no customer-facing release ships without passing the eval-suite gate, so the AIMS control is folded into the Helmsway model-change control rather than maintained as a parallel row.
- A.7.4 AI data quality assurance — data quality is enforced at the dataset lineage pointer and the eval suite; the SoA defers the named row to the Helmsway dataset lineage control.
- A.9.4 AI system retirement — no retired model holds a production key; retirement is journalised on the audit ledger through the platform lifecycle control.
- A.5
AI-P·AI policy
AI policy
Every AI control the platform ships is signed off against the AIMS policy the platform owner attests to every quarter. The policy is the document the auditor diffs against the levers and the human-override journal — same page, same quarter, named owner per row.
- A.5
AI-R·AI roles
AI roles & responsibilities
A named AI owner sits on the leadership chain and reports to the board at the next review window. Roles for the engineer training the models, the engineer shipping the lever and the engineer auditing the corridor are split on a Segregation-of-Duties principle — same way the ISMS handles privileged actions on the production rail.
- A.6
AR·AI risk register
AI risk assessment
Every AI model that pulls a lever is in the AI risk register — risk tier, named owner, tolerable residual risk, and a quarterly review window. The register rows name what changed since the last review and what the auditor pulls at the next surveillance window.
- A.6
IC·Impact categories
AI system impact categories
Each model is scored against the customer-impact categories the AIMS declares — pricing fairness, ad-spend fairness, review-voice safety — and the resulting tier gates whether the model can pull a Helmsway lever. A model that scores above the impact threshold is blocked at the eval-suite gate before it ever ships a release.
- A.8
DL·Dataset lineage
Data governance for training signals
Every training signal carries a versioned lineage pointer that names its provenance, the run that produced it and the eval pass that gates the change. An audit can trace any decision back to the data it saw — including on the eval-suite gate the AIMS review window reads from.
- A.8 · HO
HO·Human override
Human oversight & transparency
A named guardrail owner signs off every override and the override is journalised with the effect on the next bill. Inbound prompts pass an injection-screening layer; flagged inputs are refused at the guardrail — never echoed, never written back. Every model output about to write against the merchant's corridor is re-confirmed by a human-in-the-loop before it lands.
Levers under AIMS
Four automations. One named owner per lever.
Every AIMS control area in scope above maps onto a specific Helmsway automation. The four-card grid below names each lever and the AIMS controls that gate it — the inverse-direction reading a security reviewer expects after the Annex A walkthrough.
- Repricing
Repricing automation
Re-runs every connected SKU's price on the buy-box signal, within the corridor the merchant sets on the dashboard.
- A.5 — AI policy
- A.6 — impact categories
- A.8 — dataset lineage
- HO — human override
- Ad-pause
Ad-pause automation
Pauses Meta / Google / TikTok ad-sets whose ROAS drops below the merchant's corridor on the eval-suite gate.
- A.5 — AI policy
- A.6 — AI risk assessment
- A.8 — dataset lineage
- HO — human override
- Restock
Restock automation
Issues a replenishment PO when sell-through crosses the merchant's threshold and the supplier ledger confirms capacity.
- A.5 — AI roles & responsibilities
- A.6 — impact categories
- A.8 — dataset lineage
- Review-reply
Review-reply automation
Drafts a response to inbound reviews inside the voice guardrail the merchant sets, with a human-in-the-loop re-confirm before write-back.
- A.5 — AI policy
- A.6 — impact categories
- A.8 — dataset lineage
- HO — human override
Data sources
Where the AIMS draws its input from.
The four connectors below feed the platform the data the AIMS-governed models act on. Each connector ships with its own data-scope page so a reviewer reads the connector surface, the data lineage pointer, and the eval-suite gate in one pass.
AIMS risk treatment plan
How each named AIMS risk is treated.
Every named AIMS risk carries a treatment choice, a residual tier and the next review window. The risk register is the same booklet the surveillance audit diffs at the next window — four named rows below, written against the AI control tower the SoA booklet declares.
Model-output drift
Eval-suite gate + corridor re-confirmation by a human-in-the-loop before write-back
Residual: Low
Prompt-injection on inbound context
Injection-screening layer at the guardrail + journalised refusal on flagged inputs
Residual: Low
Training-signal provenance gap
Versioned lineage pointer on every training signal + dataset-change review at each shift
Residual: Low
Human-override drift
Named guardrail owner + override journal + monthly AIMS review window
Residual: Medium
Request the latest ISO 42001 report.
The AI risk register, the dataset lineage matrix and the eval-suite cadence ship on a mutual NDA under one business day. Send a note and the security contact comes back to you directly.
Replies land with the security contact, not a sales sequence.
- SOC 2
SOC 2 — Type II
Operational controls across the platform — the Trust Services Criteria a security reviewer looks for in the SOC 2 letter.
- ISO 27001
ISO/IEC 27001
Information security management system — Annex A controls, statement of applicability, surveillance audit trail.
See it on your store
See it on your store →
Skip the questionnaire — book a Scale-tier demo and watch the helm pull a lever on your Shopify store.
ISO/IEC 42001 covers the AI management system — the AIMS controls that govern every model that pulls a lever. This page walks the framework, the controls in scope, and how to request the latest report.
← Back to trust center