Governance.

Governance is not a document we publish. It is the way the work is done. The principles below are how we expect every iWeb engagement to behave, in delivery and in steady-state operation.

• Systems should remain inspectable. If we cannot show how a decision was made, the decision should not be automated.
• Automation requires boundaries. Every automated action has a defined scope, an owner, and a route to revoke it.
• Human judgement remains accountable. Tools assist named people, they do not replace them.
• Operational trust is designed, not implied. Controls are written into the system, not promised in marketing.
• Governance should be visible. Clients see the same controls we use internally.

We use AI inside delivery (code assistance, content drafting, classification, search, support triage) and inside the products we build for clients. The guardrails below apply to both contexts.

Scope of use

Each AI feature has a written purpose. Out-of-scope use is not permitted in production paths.

Model selection

Models are chosen for the task, not for novelty. We document the provider, model, and version against each feature.

Sensitive data

Customer PII, payment data, and confidential client material are excluded from third-party model training and retention by contract and by configuration.

Output handling

Generated output is treated as a draft. Material decisions, customer-facing content, and code merges require human approval.

Failure mode

Every AI path has a deterministic fallback. The system continues to function if the model is unavailable or returns low-confidence output.

No automated system at iWeb makes a final decision that affects a person, a customer balance, or a published surface, without a human in the loop.

• Code generated by AI is reviewed by a named engineer before merge.
• AI-assisted content is reviewed and signed off by a named writer or operator before publication.
• Customer-facing automations (pricing changes, stock holds, refund flows) require role-based approval from a named operator above a defined threshold.
• Operators can pause, override, or roll back any automated action without escalation.

Every system we build records who decided, what they decided, and on what basis. This is the floor, not the ceiling.

We treat client data as borrowed, not held. The boundary between iWeb systems and client systems is explicit, documented, and reviewed each engagement.

• Production data is not used in development environments. Test fixtures are synthetic or irreversibly anonymised.
• Access to production systems is named, time-bounded, and logged. No shared credentials, ever.
• Data residency follows the client contract. UK and EU residency are the default for UK-headquartered clients.
• Sub-processors are listed on request. Material changes are notified in advance, with a right of objection.

Every change to a production system, automated or not, is traceable to a person, a ticket, and a point in time. This is the same record we use to operate, the same record an auditor sees.

Source control

All production code lives in version control. Direct edits to production are not permitted.

Change record

Every release is tied to a ticket, a reviewer, and a deployment log entry.

Audit retention

Operational logs retained 12 months, security logs 24 months, governance records for the life of the engagement plus 6 years.

Client access

Enterprise clients can request a read-only feed of their environment's change record at any time.

Automation is judged on whether it makes the operator's job clearer, not on how much human work it removes. The same test applies to AI features and to ordinary scripts.

• Each automation has a named owner inside the operator team. If the owner leaves, the automation is reviewed before it continues to run.
• Automations that act on customers are rate-limited, observable in real time, and reversible.
• Silent automations are not permitted in production. Every action produces a record an operator can read.
• A quarterly review removes automations that no longer earn their place.

Accessibility is a delivery gate, not a closing audit. The detail is in the accessibility statement; the governance commitment is here.

• WCAG 2.2 AA is the minimum standard for everything we ship, our own site and client work.
• Inclusive language is reviewed at copy stage, with the same weight as legal review.
• Procurement of third-party components requires an accessibility statement from the vendor, or a remediation plan from us.

Security is treated as part of operational quality, not as a separate function bolted on at the end.

Standards

ISO/IEC 27001 control alignment. Cyber Essentials Plus on the corporate estate.

Access

Role-based, MFA-enforced, reviewed quarterly. Joiners-movers-leavers process is automated and logged.

Vulnerability

Dependency scanning in CI. Critical issues patched within 7 days, high within 30.

Incident

Named on-call. Incident lead identified within 30 minutes. Client notification within agreed contractual SLA.

Recovery

Backups tested quarterly. RPO and RTO agreed per engagement, written into the runbook.

This statement is reviewed by the Operations Board each quarter and republished annually, or sooner if a material change to practice requires it.

• The Operations Board owns the governance framework and the risk register.
• The DPO owns data-protection compliance and is independent of delivery.
• The Engineering lead owns production change control and the security posture.
• The Managing Director is accountable to the Board for the framework as a whole.