Figure 30 indicates a process for generating an audit event, but the process does not fit the actual process in all cases. the figure should be updated to indicate that event might be generated after the process is complete depending on the activity that is generating the audit event. - this issue orginated from a forum post

https://opcfoundation.org/forum/opc-ua-standard/succession-of-operations-when-generating-action-audit-events/#p2485
-copied here

"According to Part 3 Figure 30, after accepting a Client’s request (e.g. , a Write to a Variable), the Server
firstly, generates an Action AuditEvent and
subsequently processes the Action, writing to the Variable.
Question 1: Is this succession mandatory when generating Action AuditEvents?

As I take it, the new Compliance Test Tool of Version 1.04 proceeds inversely with Security AuditEvents (firstly, performs the action and generates the AuditEvent afterwards).

Question 2: What exactly is the meaning of a TRUE Value of the Status in an Action AuditEvent:

1)The Server accepted the Client’s Request and will process the Action subsequently
2)The Server has performed the Client’s Request (independently of the Action’s StatusCode)
3)The Server completed the Client’s Request with a ‘Good’ StatusCode. A StatusCode ‘Bad’ (or ‘Uncertain’?) would implicate the Value FALSE of the AuditEvent Status property."
[Paul - my answer to question 2 is that the actual audit event typically follows option 3 ]