Page 206 - CyberSecurityEssentialsEnglish

●Remember: Section summary
• Key idea: The four terms differ in scope, and using them loosely hides who owns what.
• Practical decision: Name the level you are working at before designing anything, and
write the procedure once the workflow is stable.
• Mistake to avoid: Calling a single task a process, or writing a procedure for work that
still changes every week.

5.3 Anatomy of a Workflow: What Must Be Documented?

◆ Key idea: an operable workflow needs documentation.

An operable workflow needs more than a general description. It must define the event
that triggers it, the acceptable inputs, the process owner, the roles, the rules, the
decisions, the exceptions, the outputs, the records, and the performance indicators.

The trigger is the event that starts the work: an email arriving, a file being uploaded, a
periodic date falling due, an indicator crossing a threshold, or a person’s request. If we do
not define the trigger, the process becomes work that depends on someone remembering.

A trigger may be automatic, but that does not mean the rest of the process must be.

Inputs are not merely files. Describe their type, format, version, source, mandatory fields,
time period, and sensitivity. A good input reduces uncertainty. Build an initial check that
stops the process if the file is empty, the period undefined, or the version unapproved.

The process owner is responsible for the soundness of the process as a whole, while a task

owner is responsible for one particular step. AI may write a draft, but it does not become an
owner and carries no responsibility. Clear role names prevent the phenomenon of “I thought
someone else had checked it.” Use a responsibility model to identify who is responsible for

execution, who is accountable for approval, who is consulted, and who is informed.

A decision point opens more than one path. For example: if confidence in a data extraction
is high, the result moves to a quick review; if it is low, it goes to an extended review. The

decision must rest on a rule or a criterion, not on the mood of the tool. Where no numerical
criterion exists, use a human checklist.

An exception path sets out what happens when the normal case fails: a corrupted file, a
contradictory source, a request outside scope, or a result that does not meet the criterion.

A process with no exceptions looks elegant on a diagram and fails in reality. It must also say
when to stop, when to retry, and when to escalate to an expert.

A quality gate is a point beyond which an output may not pass before a defined check is
completed. It may be automatic, such as matching fields against a schema, or human, such

as approving recommendations. The gate must be proportionate to the risk; excessive

205