How to answer
Do you have a documented change management process?
At fifteen people this is not a change advisory board. It is whether your pipeline records who changed what.
Yes. Changes are tracked in version control, reviewed and approved before merge, and deployed through an automated pipeline that records who deployed what and when. Emergency changes follow the same path and are reviewed [the next working day].
Square brackets are yours to fill in. FillTrust grades an answer like this confirmed in your documents when your documents support it.
- Answered from
- Your engineering handbook, and the change management section of your SOC 2 report.
- Evidence to attach
- Occasionally a sample of recent changes showing approval and deployment records. Your version control and CI history is usually accepted as this.
- Where it is asked
- CAIQ v4.0 · CCC-01SIG LiteISO 27001 Annex A · A.8.32
This question was written for enterprises with change advisory boards, and it lands on small companies who read it and reach for language they do not need. A reviewer assessing a fifteen-person SaaS is looking for an audit trail and a gate, not a committee.
The good news is that a normal engineering setup already produces both. Version control records what changed and who wrote it. A required review records who approved it. A CI pipeline records who deployed it and when. That is a documented change management process, and the only thing usually missing is a paragraph in a document saying so.
Emergency changes are the interesting half. Every team has pushed a fix at 2am. The question is not whether that happens, it is whether there is a rule for it: who may do it, and what happens afterwards. "Emergency changes follow the same pipeline and are reviewed the next working day" is a complete answer and takes one sentence to make true.
Infrastructure is the gap that catches people. If your application changes go through review and your cloud configuration is changed by clicking in a console, then half your production surface is outside the process you just described. If your infrastructure is in code, say so explicitly, because it is a strong answer and reviewers notice its absence. If it is not, the honest version is that application changes follow the pipeline and infrastructure changes are made by a named small group, which is at least a control.
Testing and rollback. Fuller versions of this question ask whether changes are tested before release and whether you can roll back. Automated tests in the pipeline and the ability to redeploy the previous version cover both, and both are worth one sentence each.
Nothing here needs new process. It needs one page in your handbook describing the process you already run, at which point this question and the four others that ask it differently all become confirmed answers drawn from a document.
How this one goes wrong
Specific to this question, not general advice.
- Describing an approval board you do not have. Reviewers do not expect a CAB at fifteen people; they expect an audit trail, which your pipeline already produces.
- Having no answer for emergency changes. Every team has broken glass at some point, and the question is whether the exception has a rule.
- Forgetting infrastructure. If your cloud configuration is changed by hand in a console, that is a change outside the process you just described.