Controls and operating authority
The control design specifies the system’s access, permitted actions and required evidence. Within those limits, the operating question is how much work it can complete reliably and where human involvement contributes to the result.
Access and actions
Permissions are enforced by the application, not by the model.
Access is enforced by the application and connected systems. Retrieved documents cannot grant permissions or alter approval rules. The implementation records the difference between a proposed action, an authorised instruction and an action confirmed by the destination system.
Independent verification
Checked independently of the model
Calculations, reconciliations and defined conditions should be checked in tested code where appropriate. A model agreeing with its own earlier answer provides limited independent assurance. Material conclusions need the relevant sources, calculations and unresolved discrepancies available for inspection.
Verification should require substantially less effort than performing the work again. Where a reviewer must reconstruct the entire result, the design has retained much of the original cost and may have created a weak review in practice.
Human review
Three kinds of decision in every service
Review requirements follow the consequence of the action, the applicable obligations and demonstrated performance. The design sets out three kinds of decision, specific to each service.
- 1
Reserved decisions
Approvals, judgments and client advice that only an authorised person may give on a case.
- 2
Escalation conditions
The conditions under which the system stops and refers a case, with all of its evidence.
- 3
Approved scope
The actions the system may complete itself, inside the limits approved for each service.
Human accountability does not require a person to perform or approve every intermediate step. Equally, a nominal approval with no usable evidence adds little control.
Testing and failure response
What every test includes
The evidence includes what the system actually did and what escaped its checks. Critical access or action failures have explicit stop and recovery rules.
- Missing information
- Conflicting information
- Restricted records
- Unexpected document instructions
- Unavailable services
- Partial execution
Model and process changes
Business requirements and model limitations are different kinds of constraint.
Access rules and approval obligations remain in force. A workaround or manual step introduced because a previous model could not handle the task should be reassessed when the capability changes.
Material changes are evaluated against the affected work and the approved operating scope. The purpose is to permit useful improvements while retaining control of the process and its approvals.
Operating responsibilities
Defined for each firm
The engagement defines each of these for the particular firm, as part of its operating design and supplier review:
- 1Information handling
- 2Providers
- 3Monitoring
- 4Incident response
- 5Recovery
- 6Change ownership
Delivery, measurement and an example
-
Delivery method
The first phase, the five stages of every service and what is agreed before the work starts.
-
Measurement
The human effort and total cost of each completed service, at the required standard.
-
Reporting example
An invented reporting case showing how sources, calculation and review fit together.