Flowable audit records for NIST SP 800-53 AU-2 and AU-3

Which NIST SP 800-53 AU-2 and AU-3 requirements Flowable helps you evidence

A team running BPMN or CMMN workflows over regulated data needs to show auditors which events are logged and what each record holds. Flowable history, event logging and MDC log fields can supply much of that evidence for AU-2 and AU-3, but the decisions about what to log, how often to review that selection and how logs are protected stay with your organization. NIST's AU-2 requires you to name the event types the system can log, explain why that selection supports after-the-fact investigation and review it at a defined frequency. AU-3 asks that each audit record capture the type of event, when and where it occurred, its source, its outcome and the identity of the individuals, subjects or objects involved. Flowable's history levels, task and variable history, and the identity of the user completing a task map onto several of these fields, but the mapping is yours to document and test.

Start by building a control mapping for each workflow that touches regulated data. For each event type, record the Flowable source (for example, history entries for process instance start, task completion or variable updates, or application log lines carrying MDC fields such as user or request identifiers), the history level that produces it, and the gaps where an AU-3 element is absent. Confirm in your own environment whether the identity recorded for a task completion comes from your authenticated session or from a default value, and whether timestamps and outcomes are captured in the fields your auditors will sample. Also confirm which events Flowable does not record by default and whether your application must write them. The Flowable configuration docs are the natural starting point for history settings.

DeployOpen plans, configures and documents these logging paths in infrastructure you control, and prepares the evidence an assessor would examine. DeployOpen does not issue audit reports, attestations or certifications; an independent assessor or the authorizing body makes those determinations. AU-2 and AU-3 are selected in the low, moderate and high baselines of SP 800-53B, so the depth of logging you need depends on the impact level of your system. Confirm the baseline that applies to your system with the authority that governs it before scoping the work.

Mapping AU-2 and AU-3 requirements to Flowable capabilities and configuration

This table maps each AU-2 requirement and AU-3 content element to the Flowable history data, configuration or MDC field that supports it, and states what your team must add. Read the middle column as the starting point and the right column as the work your team owns and must evidence. The main takeaway is that the engine supplies process history, while event selection, review and several identity and location fields are design decisions for your organization.

Requirement or element	Flowable capability or configuration	What your team must add
AU-2: identify event types	History tables cover process, case, task and job activity at the configured history level.	List every event type the system can log, including admin, deployment and identity changes.
AU-2: specify logged types and frequency	Set the history level in configuration. Confirm which level records variables and task completion.	Record which types are logged and how often logs are exported or checked.
AU-2: document selection for investigations	The engine does not record why a selection exists.	Write a selection record that maps each logged type to an investigation question, and get it approved.
AU-2: review at a defined frequency	The engine has no review workflow for the logging selection.	Assign an owner, a review cadence and a sign-off step through your governance process.
AU-3: event type and time	History entries carry activity type, process definition and timestamps. MySQL versions below 5.6.4 lack millisecond precision.	Confirm the history fields your level writes and keep time sources synchronized across nodes.
AU-3: where and source of the event	History holds process definition and deployment references. Node or host identity is not a default history field.	Add host, node and calling service identity through MDC fields or your logging configuration.
AU-3: outcome	History shows completed, deleted or terminated states. Failed jobs remain in job tables until retried.	Log job failures and retries to your logging pipeline so each outcome is recorded.
AU-3: identities of individuals, subjects and objects	User IDs appear on completed tasks when the application sets the authenticated user. Variables can hold personal data.	Confirm authenticated users for REST and service calls, and limit personal data in variables (AU-3(3) privacy baseline).

How Flowable history, event logging and MDC fields produce audit content

No single Flowable source meets AU-3 on its own, so the first decision is which source carries which element. Engine history, governed by the history level in the Flowable configuration docs, is the durable record of process instances, activities, tasks and variables, and it is usually the first source an auditor asks for. Event logging records engine events as they occur, which can capture activity the history tables do not keep. MDC log fields are the third source: values such as a request or user identifier that the application places in the logging context so each line it writes carries them. Confirm which history level you need, which event types each setting produces, and whether the engine or your application populates any MDC keys in your Flowable version.

Several AU-3 elements are not supplied by any of the three alone. History records which user completed a task, but it does not establish the source system or host that made an API call, and it does not verify identity for a service account used by an integration. When a process starts through the Flowable REST application, the engine stores whatever user value the calling application passes in, so the authentication layer in front of Flowable must supply the verified identity and the request source. Trace one API call from the gateway through the engine into the history and event records, and check each AU-3 element at every hop. Record each element that no source supplies as a gap for your own logging or gateway configuration to close.

Before you fix the AU-2 selection, run a controlled test. Start one instance through the REST application with a known test account, complete a task, change a variable and then compare what appears in history, the event log and the application log. Keep the Spring Boot actuator at /actuator/flowable out of the evidence set, since the Flowable Spring Boot docs describe it as a monitoring endpoint for running processes, not an audit record. Note the outcome of each comparison, the version tested and the retention settings that apply, because the selection you document under AU-2 must explain why those records support after-the-fact investigation.

What audit evidence Flowable produces and how to keep it

An assessor testing AU-2 and AU-3 will ask for a written event selection, sampled audit records and proof that the logs themselves are protected. Each artifact below comes from a different place in the Flowable stack, so each needs its own owner, storage location and review step.

Written AU-2 event selection

This is the document that lists which Flowable event types you log, why that selection supports after-the-fact investigation, and how often you review it. Record the history level, event listeners and application log categories you chose, then tie each to a specific event type. Keep it under version control with a named owner, because an assessor will compare the document against the running configuration.

History tables sampled for AU-3 fields

Flowable history tables hold who started and completed tasks, when, and with what outcome, which maps directly to the AU-3 content fields. An assessor will pick sample process instances and check that each record shows the event type, timestamp, source, outcome and identity. Run that check yourself before the assessment, on instances from each process definition in scope.

Event log exports

Where you enable the event log, exports show the sequence of engine events for each instance, which helps answer the question of what happened between two history entries. Confirm the export format, where files are written and how long they persist in your environment. Test that a single instance can be reconstructed end to end from the export alone.

MDC-tagged application logs

Application logs carrying MDC fields such as process instance and user identifiers let you join engine activity to request and infrastructure logs. Check that the fields are populated on every code path, including asynchronous jobs that run on the executor thread pool, where context is easy to lose. Sample a few jobs and confirm the identifiers are present.

Selection review record

AU-2 requires the event selection to be reviewed at a defined frequency, so keep dated records of each review, who performed it and what changed. A change to the history level or a new process definition should trigger a review outside the normal schedule. Assessors often ask for the most recent review and the change that prompted it.

Protection and retention of log stores

Logs and history are only evidence if they cannot be altered without detection and are kept long enough to cover your investigation and assessment window. Restrict write and delete access on the database and log sinks, forward copies to a separate store, and set retention in writing. Confirm with your own policy owner what retention period applies, since NIST does not set one for AU-2 or AU-3.

Configuring Flowable audit logging for an AU-2 review

This sequence turns an AU-2 event selection into engine settings, application logging and test evidence, so the selection you document is the one the system actually produces. It ends with a scheduled review that keeps the record current.

Inventory engine events and user actions
The process owner and the security engineer list the Flowable engine events and user actions that matter for after-the-fact investigation, such as process starts, task claims and completions, variable changes on decisions, deployments of process and case definitions, and administrative changes to identity data. Each item is tied to a business workflow and an owner. The output is a written event inventory that names what the system can log and what the organization needs to see, which is the input AU-2 asks you to justify.
Set history level and event logging
The platform engineer maps each inventory item to the history and event logging settings in the Flowable configuration for the chosen engine version. Confirm in the configuration documentation which history level captures task-level and variable-level detail, and which event types can be written to the event log. Record the settings in version control with the deployment configuration. The output is a configuration baseline in which every inventory item either has a setting that captures it or a documented reason it is not captured.
Add MDC fields to application logging
The application team adds Mapped Diagnostic Context fields to the application logging so that log lines written around engine activity carry the user identity, process instance identifier, task identifier, and correlation identifier. Use the logging framework in your Spring or servlet stack, and confirm which fields the engine itself writes. The output is a log format in which a single engine action can be traced from the history record to the application log line through shared identifiers.
Test that records contain the AU-3 elements
The QA lead runs scripted test cases for each inventory item in a non-production environment and checks each resulting record against the AU-3 elements: event type, date and time, location or source, outcome, and the identities of the users, subjects or objects involved. Where a required element is missing, the team adjusts the configuration or the application code and reruns the test. The output is a dated test record showing which events produced complete records, along with the gaps that were closed or accepted.
Document the AU-2 selection and rationale
The compliance lead writes the selected event types, the frequency at which each is logged, and the reason each supports after-the-fact incident investigation. The document references the inventory, the configuration baseline and the test results, and it names the owner responsible for maintaining it. Confirm the control statement wording against the current NIST CPRT entry for AU-2 before publishing. The output is a signed AU-2 selection record that an assessor can trace to the running system.
Schedule the AU-2 selection review
The control owner sets a review cadence for the event selection and records it in the governance calendar, with the review frequency defined by the organization's own policy. Each review compares the current inventory and configuration with the documented selection, checks for new Flowable process or case definitions that add events, and confirms that the test cases still pass after upgrades. The output is a review log with dated decisions and any changes to the configuration or documentation.

How much work is Flowable audit logging for NIST 800-53 AU-2 and AU-3

What drives the cost of Flowable audit logging for AU-2 and AU-3?

The main driver is how many process definitions, case models and decision tables need audit coverage, and how many distinct event types each one produces. Cost rises with the number of systems that emit Flowable events, the number of teams that must agree on the event selection, and the amount of custom delegate code that must write its own audit fields. Work falls into two parts: the one-time design of the event selection and record content, and the configuration and testing that follows. Ongoing costs are the periodic review of the selection that AU-2 requires and any retainer for support. Ask any quote to separate these two parts and to list which systems and process families are covered.

How long does Flowable AU-2 and AU-3 logging work take?

Duration depends mainly on the number of process families in scope, the number of deployment environments, and how far the current history configuration already matches the record content you need. A single engine with a small set of processes is a very different job from a multi-engine estate with custom delegates and an external log platform. The fixed-scope agreement sets the timeline in writing before work starts, so ask for a plan that breaks the work into design, configuration, testing and handover, with the dependencies on your log platform and data owners named. No duration is given here because none has been established for your environment.

What must our team supply before the work starts?

Three inputs carry most of the schedule risk:

A process inventory listing every BPMN, CMMN and DMN model in use, the systems that call them, and the environments where they run.
Named data owners who can say which variables hold personal or sensitive data and how long records must be kept.
A log platform owner who confirms where application and audit logs are shipped, how they are retained, and who can query them.

You should also supply the current Flowable version and database type, along with any existing audit or event logging configuration, so the design starts from what is already running.

Can our own team implement AU-2 and AU-3 logging for Flowable?

Yes, an internal team can do this if it has Flowable engine skills, Java and Spring experience, and staff who understand the control requirements. The hard part is rarely the configuration itself. It is agreeing the event selection, explaining in writing why it supports after-the-fact investigations, and proving that each record carries the required content. AU-2 expects the organization to identify event types, coordinate with other entities that need the information and review the selection at a defined frequency, so the decisions need an owner and a document. If your team lacks capacity or has not run Flowable in a regulated audit before, a fixed-scope partner engagement can cover the design and handover while your staff keep ownership.

What should a quote for this work include?

A quote should follow from a written scope and list the deliverables in plain terms. Ask it to name the Flowable engines and process families covered, the event types proposed for logging with the reason for each, the AU-3 content fields mapped to each event, and the MDC or log fields used to carry context. It should state which environments are configured and tested, how the log platform integration is handled, what documentation is handed over, and what is excluded. Also ask for the assumptions about your inputs, the review of the event selection after go-live, and any recurring support or retainer, shown separately from the one-time work. DeployOpen does not publish a price list, so the quote is the point where cost is set.

What goes wrong when AU-3 audit records lack required content?

The most common gap is an event that is logged but cannot answer who did it, what happened, when and where it happened, from which source, and with what outcome. In Flowable this often appears when task completions record a user but the process instance, the action or the outcome is missing from the stored record, or when timestamps and identifiers differ between the history tables and the application log. Another frequent problem is logging personal data inside variable values that AU-3 does not need, which conflicts with the privacy baseline's limit on PII elements. Test by picking a sample of events, reading the stored record and checking each AU-3 field against it, and confirm your log platform keeps the fields intact.

Does the NIST control requirement fix how many events we must log?

No. AU-2 requires the organization to decide which event types the system can log, document why that selection supports after-the-fact incident investigations, and review it at a defined frequency. NIST does not provide a fixed list of events or a number of records for a Flowable deployment. The selection depends on your system's impact level, the baseline you are assessed against, and your own risk management process. Confirm the baseline and any tailoring with your assessor before finalizing the list, and confirm the review frequency with your governance body.

Which baseline and assessment steps apply to your system

AU-2 applies across every baseline you are likely to see, including the low, moderate and high control baselines and the privacy baseline, so the event selection described in this topic is not optional for a system in scope of SP 800-53B. AU-3 is selected for the low, moderate and high baselines but not for the privacy baseline. That difference matters if your Flowable workflows handle personal information under a privacy-only assessment, because the content requirements of AU-3 may then not be assessed in the same way, while the event selection under AU-2 still is. Confirm with your authorizing official or assessor which baseline your system carries and whether any tailoring or overlay changes the selection.

Assessors test these controls with the examine, interview and test methods defined in SP 800-53A Rev. 5. For AU-2 they examine the documented event types, interview the people who maintain the logging configuration and the people who rely on it for investigations, and test whether the Flowable history level, event logging and application log fields actually produce the records the plan describes. Expect the assessor to ask who selected the event types, when the selection was last reviewed, and how the selection supports after-the-fact investigation. Ask your assessor early which assessment objects they will sample, such as a set of process instances, and whether they will run a live test in a non-production environment. The current assessment procedures are available in the NIST SP 800-53A Rev. 5 publication.

Confirm three things before you build anything: the baseline your system is assessed against, whether AU-2 and AU-3 are inherited from a shared service or implemented by your application team, and which enhancements your baseline selects, since AU-3(1) is part of the moderate and high baselines. Record the answers in the system security plan so the Flowable configuration in later sections can be traced to a specific requirement. If your organization uses a compliance tool or assessor template, check that its AU-2 and AU-3 wording matches the current SP 800-53 Release 5.2.0 control text, because earlier release labels and enhancement numbers differ.

How DeployOpen scopes and delivers Flowable audit configuration and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including Flowable engines. For Flowable audit records mapped to NIST SP 800-53 AU-2 and AU-3, we agree the event list and record content in writing, configure the engine to produce them, and hand over the evidence your assessors will sample.

How we scope

Engagements are fixed-scope, with the Flowable engines, event types and AU-3 fields agreed in writing before work starts.
We inventory which BPMN, CMMN and DMN processes touch systems in scope and which events each one must record.
The written scope names the history level, log destinations and identity sources the audit configuration depends on.
Scope also states who reviews the AU-2 event selection and at what frequency, as the control requires.

How we build

We configure Flowable history levels and event logging so the agreed event types are captured with the required fields.
We connect MDC log fields so each record carries the acting identity, timestamp, source and outcome.
We test the configuration against sample process runs and confirm that records are complete, ordered and queryable.
We document the selection rationale and the assessment evidence for each AU-2 and AU-3 requirement in the written scope.

How we hand over

You receive the configuration, the event selection record and the mapping from each AU-3 field to its Flowable source.
Runbooks cover how to query history and logs during an investigation and how to export records for review.
We walk your security, compliance and platform teams through the evidence an assessor is likely to request.
Deliverables are stored in your infrastructure, so your team keeps full control of the audit trail.

How we support

Ongoing support, upgrades and periodic review of the AU-2 event selection are available as a retainer.
Retainers cover re-testing audit records after Flowable upgrades or changes to processes that add new event types.
We help you prepare evidence for your own assessors, while independent auditors and certification bodies make the determinations.
Confirm with your assessor which control baseline and evidence format apply to your system before the scope is signed.