SI Control Objectives (SICOB)

Control Objectives for SI Systems (SICOB) is the enterprise operating model for governing and managing artificial intelligence. It is how the organisation establishes, implements, operates, monitors, reviews, maintains and continually improves its SI ecosystem.

SICOB does not replace the definition of SI governance. It turns those outcomes into assigned processes, controls, measures and assurance.

Where SICOB sits

Three layers, one accountability model. The governing body sets outcomes. SICOB turns those outcomes into work. The SI Governance Platform applies the model to live SI uses and keeps the evidence.

• Governance Framework - outcomes against which the governing body holds management to account.
• SICOB - process model and workbench: forty control objectives in five families, mapped to law and standards.
• Governance Platform - software that registers live SI uses, attaches policy, observes or enforces controls at runtime, and retains evidence.

Select outcomes first, then the process model, then software. A platform without agreed outcomes implements activity with no test of success.

The framework SICOB puts to work

The SI governance framework is the set of outcomes against which the governing body holds management to account for the organisation's use of SI. It does not redefine governance. It states how the four outcomes are tested in operation.

The framework does not replace law, standards or internal policy. Those instruments are mapped onto SICOB and, where used, applied through the platform. The governing body's work is to evaluate, direct and monitor. Management's work is to align, plan, build, run and assure. Every material SI outcome should have both a governing-body role and a management owner.

• Ethical culture - tested by whether responsible-SI policy is approved, known and used; whether incentives and escalation support that policy; and whether exceptions and incidents are handled in line with stated values.
• Sustainable performance and value creation - tested by whether SI use is tied to purpose and strategy; whether the portfolio is known and prioritised; and whether expected value is compared with realised value, including the cost of risk, change and recovery.
• Adequate and effective control of SI resources and risks - tested by whether the governing body can see the estate of SI uses; whether risk is treated inside the organisation's business-risk profile; whether third-party and embedded SI sit in the same control system; and whether controls operate at runtime, not only as documents.
• Trust, reputation and legitimacy - tested by whether decisions leave named work products; whether accountability remains visible across legal-entity boundaries; and whether one set of processes can satisfy multiple obligations without a parallel paper framework.

An outcome is developed only when the loop is closed: policy, assigned owner, work product and review. Design factors in SICOB set how deep each process goes. The outcomes stay the same; the practices scale.

Forty control objectives in five families

For SI to function effectively, many activities need to be identified and managed. Any activity that consumes resources to turn inputs into outputs is a process, and the output of one process is often the input to the next. SICOB treats these activities as a connected system so that policy, risk controls, delivery and oversight stay aligned.

Forty SI control objectives turn stakeholder goals into assigned processes, controls, metrics and assurance. They sit in five families:

• Evaluate, Direct and Monitor (EDM) - governing-body evaluation, direction and oversight;
• Align, Plan and Organise (APO) - strategy, architecture, portfolio, people and organisation;
• Build, Acquire and Implement (BAI) - design, acquisition, build, change and deployment;
• Deliver, Service and Support (DSS) - operations, continuity, incidents and service;
• Monitor, Evaluate and Assess (MEA) - performance, conformance, internal control and assurance.

The families cascade stakeholder goals into named processes, enforceable controls, measures and independent assurance. Design factors set how much of each process is implemented, and to what depth, so the organisation does not treat "all forty at the highest maturity" as a plan.

Mapping spine

SICOB is the spine other instruments map onto, including the EU AI Act, the UK GDPR / EU GDPR, quality-management system requirements, security and service-management practice such as ISO/IEC 27001, and SI and IT governance frameworks including ISO/IEC 38500, ISO/IEC 38507 and ISO/IEC 42001-aligned elements.

A mapping is a claim only when it is explicit: one process-control activity named against a named article, clause or control. Individual maps are maintained in the workbench.

SICOB workbench

The forty processes are combined in the SICOB workbench: a single web application with group-based, role-restricted access, versioned signed archives, and user and administrator manuals. The workbench turns the forty SI control objectives into assigned practices, controls, measures and assurance. It is not forty separate applications.

The workbench is the process system. The SI governance platform is the runtime system for live SI uses. They are complementary: the workbench holds how the organisation governs; the platform holds what is running and whether controls fired.

What SICOB gives the organisation

• One accountability model. Every SI system outcome has a governing-body role (evaluate, direct, monitor) and a management owner.
• Business language for technology. Goals cascade from enterprise objectives, so a control can be shown to exist for a reason, not only that it exists.
• Complete lifecycle, not a control list. Strategy, architecture, build, run, continuity and assurance sit in one model, together with governance, portfolio, people, vendors and change.
• Tailoring instead of theatre. Depth is concentrated where risk and value are highest.
• Auditability. Practices produce named work products. Internal audit and regulators can sample a process, not a slide deck.
• Reuse across obligations. One process-control activity can support more than one instrument when the mapping is explicit.
• A stable spine when technology changes. Agents and models change quickly; benefits, risk, change, incidents and performance do not.

Software may automate inventory, policy, runtime guardrails, monitoring and evidence. It does not replace the governing body's duty to evaluate, direct and monitor.