Govern change
Every change is reviewed, approved and recorded before it takes effect, which gives the evidence an auditor asks for.
A change to the model is made in a project, where it is reviewed, approved and only then activated, with a record of who did what. It is never made in place.
Change only through projects
Every change is made in a project, i.e. its own copy of the model, with its own team, taken through phases and gates until it is activated. Projects which target execution add a testing phase.
Clear roles, and sign-off that means something
Project roles say who moves a project on and who signs what. Where regulations apply, a project adds the checklists they require, and a project is approved by signature, on signed test reports where it was tested.
Many projects at once
Projects on the same model run side by side and are brought up to date as others are activated. A project nobody works on any more is archived, and can be restored.
In the manual: keeping projects up to date
A record for the auditor
The model’s history and an exportable audit log record who changed, reviewed and approved what.
Who sees what
Access is decided per responsibility domain, on top of team membership, with separation of duties on checklist signatures. Personal data is pseudonymised and can be erased.
In the manual: security policies
For architects
- The project life cycle, with a Testing phase for projects which target execution.
- Regulatory regimes and project governance profiles; project roles.
- Test reports are signed by the execution environment that produced them.
- Archiving, team membership, separation of duties and data protection.