Flowable logging for ISO 27001 A.8.15 and records protection

Which ISO 27001 logging and records controls Flowable helps you evidence

A Flowable-based process application can directly support two ISO/IEC 27001:2022 controls: A.8.15 Logging, which asks that activities, exceptions, faults and other relevant events are recorded, stored, protected and analyzed, and A.5.33 Protection of records, which asks that records are protected from loss, destruction, falsification and unauthorized access or release. The engines do not satisfy either control on their own. Log storage, log access, administrator logs, time synchronization and log review sit with your infrastructure and operations teams, and record protection depends on database permissions, backups and application authorization. DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue audit reports or certifications. The ISMS certification body and its auditor decide whether your implementation conforms to ISO/IEC 27001:2022.

Flowable produces the raw material an auditor will sample. The history data written to the database records process and task activity with timestamps and the variables your application chooses to keep, and the async executor records job and lock data for timers and background work. If your identity service is replaced with one connected to your directory, completed tasks can be tied to named accounts rather than generic users. Before you rely on any of this, confirm which history level and event logging options your Flowable version provides and what each one writes. Check the supported database and its timestamp precision as well. The configuration documentation notes that MySQL versions below 5.6.4 lack millisecond precision, which affects how reliably you can order events in evidence.

Decide early which Flowable records count as A.8.15 evidence and which count as A.5.33 records, then assign each one a retention period, a storage location and an owner. Application logs need to reach a central store that your team protects and monitors, while history tables need database-level protection, tested backups and a documented cleanup schedule. Ask your certification body and auditor which sampling approach they will use, because the mapping is not one-to-one. NIST's crosswalk relates A.8.15 to several AU family controls and A.5.33 to AU-9 Protection of Audit Information, and it cautions that mapped controls are not always equivalent. Use that crosswalk as a starting point for your own matrix, and review the result with your auditor before the assessment.

Mapping A.8.15 and A.5.33 requirements to Flowable capabilities and configuration

This table maps ISO/IEC 27001:2022 controls A.8.15 and A.5.33 to Flowable history, event logging, database and monitoring features, with the configuration to confirm and the evidence an auditor samples. Read each row as a question: what the requirement asks, what the engine provides, what you must set, and what appears in the record. The main takeaway is that Flowable supplies history and logging inputs, while protection, retention and access controls depend on your database, log platform and access model.

Requirement	Flowable capability	Configuration to confirm	What the auditor sees
A.8.15 produce logs (predecessors A.12.4.1 and A.12.4.3)	History records process, case and task activity. Event logging and application logs cover engine events and exceptions.	History level set to capture task and variable changes, event logging enabled, deployments and admin actions logged.	Sampled instance history showing who started, completed or changed each step, plus deployment records.
A.8.15 store logs (predecessor A.12.4.2)	History lives in a supported database such as PostgreSQL, MySQL, Oracle, DB2 or Microsoft SQL Server.	Engine database account limited to required privileges. Confirm MySQL version, since versions below 5.6.4 lack millisecond precision.	Database permission list, log destination with retention settings, and access reviews for the engine account.
A.8.15 protect logs from change and deletion	History tables are writable by the engine and by any direct SQL access. Confirm with the vendor whether any tamper-evidence exists.	Forward application and engine logs to a central store the application cannot edit. Restrict delete rights on history tables.	Records of who can alter or purge history, and evidence that logs are copied off the system.
A.8.15 analyze logs (A.12.4.3 operator review)	Spring Boot actuator endpoint at /actuator/flowable monitors running processes. Async executor failures surface as failed jobs.	Actuator exposed only on internal networks. Alerts on failed jobs and exceptions. Review schedule documented.	Review records, alerts raised, and how exceptions and failed jobs were triaged.
A.5.33 protection from loss and destruction	Process definitions, runtime data and history sit in the database, so database backups cover engine state.	Scheduled backups that include history tables, a tested restore, and retention periods matched to your records policy.	Backup schedule, restore test records, and retention settings for process history.
A.5.33 protection from falsification, unauthorized access and release	Authorization checks are left to the application. Identity can be replaced by implementing the IdmIdentityService interface.	Users mapped to a directory service. Access to history queries and APIs restricted. Export of history controlled.	Access lists for history queries and APIs, and logs of history exports.
A.5.33 predecessor A.18.1.3 and engine versions	Flowable 8.0.0 was released February 27, 2026, with a new Spring Boot 4 and Jackson 3 baseline.	Record the engine version and history configuration in change records for each period under review.	Version history showing which engine and records settings applied at each point in the audit period.
Cross-references (NIST SP 800-53 AU family, ENISA point 3.2)	NIST relates A.8.15 to AU-2, AU-3, AU-6, AU-9, AU-11, AU-12 and AU-14. ENISA links it to NIS2 point 3.2.	Use cross-references as starting points and confirm each control statement against your own evidence.	Assessor tests your evidence against each control statement, and mapped controls may differ in scope.

How Flowable history, event logging and application logs differ

An auditor testing A.8.15 Logging will expect to see that a Flowable application produces logs that record activities, exceptions and faults, and that those logs are stored and protected. Flowable does not give you one log. It gives you three record sources with different jobs: history tables, which the engine writes according to the configured history level; event logging, which records engine events when you enable it; and application logs, which your host application writes through its own logging framework. Each captures different facts, and each omits some of the facts the others hold, so a sample that reads only one of them will miss whole categories of activity.

History tables hold the record of process and case instances, activities, tasks, variables and identity links, and they are the source most teams point to first. The amount they contain is set by the history level, so the first check is to confirm which levels your version offers and which one is configured, using the Flowable configuration docs for that release. Lower levels omit detail such as variable values or activity timing, and history does not capture stack traces, failed HTTP calls or errors thrown by your delegates unless those surface as engine state. Confirm also how history cleanup is scheduled, because a short retention setting can remove evidence before your audit period closes.

Application logs written by the host are where exceptions, faults and the surrounding context of a failed job usually appear, including the request, user and infrastructure details your framework adds. They omit the engine's own state unless your code writes it out. Event logging sits between these two sources: confirm in your version's docs whether it is enabled, which event types it covers and where it writes. For A.8.15, an auditor should be able to trace one business transaction across all three sources, and you should test that trace before the assessment begins.

Evidence an auditor can sample from Flowable records

An auditor testing A.8.15 and A.5.33 picks a sample of events and asks you to reproduce them. The cards below cover the Flowable records most often sampled, how to export each one, and how to keep the export unchanged after it leaves the engine database.

Task completion records

Each completed user task should show who completed it, when, and with which outcome. In Flowable this comes from the history tables when the history level captures task completion details. Confirm that the authenticated user is recorded rather than a shared service account, because a sampled task with a generic user cannot be attributed. Export the sample with the task ID, process instance ID and completion timestamp, then store the export with a hash so a later change is detectable.

Process instance start and end records

For each sampled instance, the auditor expects a start time, an end time or open status, the starting actor and the definition version used. These come from the historic process instance data. Check that retention in the history tables covers the full audit period, since a record removed by a cleanup job cannot be sampled later. Keep a dated export of the instance list and record the query used to produce it, so the same sample can be rerun.

Failed job and error records

Failed async jobs and exceptions are part of the event evidence A.8.15 asks you to produce and analyze. Flowable keeps job records with exception details and retry counts, which show whether a fault was handled or left open. Confirm that the job tables are included in your backup and export routine, and that failed jobs are reviewed on a schedule with the outcome written down. Export open failures and their resolution notes together.

Process definition deployment history

Auditors often ask which version of a process was live on a given date. The deployment and process definition tables show each deployment, its version and its resource, which lets you tie a sampled instance to the model that ran it. Store the BPMN and DMN resources in version control and keep the deployment identifiers alongside them. Confirm that the stored model matches the deployed one by comparing checksums during each release.

Log retention and access records

Application logs, database backups and the audit exports need their own retention periods, separate from Flowable history cleaning. Record the retention setting for each store, who can read or delete it, and when access was last reviewed. Confirm with your logging platform how access events on the log store itself are recorded. This evidence supports the A.8.15 requirement that logs are protected and the A.5.33 requirement that records are protected from unauthorized access and falsification.

Log review procedure and sign-off

Logs have limited value unless someone reviews them. Write a procedure that names the reviewer, the frequency, the events checked and how exceptions are escalated, then keep a dated record for each review. An auditor will sample a few review records and check that the findings match the logs for the same period. Store the signed review records in the same controlled location as the exports they cite, so the sample can be traced from review to source.

Configuring Flowable logging for an A.8.15 evidence trail

This sequence sets up the Flowable history, event and application log settings so that an auditor can sample who did what, when, and where the record is kept. Each step names the check that closes it, and each step lists what to confirm against the Flowable version your team runs.

Confirm database and timestamp precision
Start with the database that holds the Flowable runtime and history tables. The configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types, and MySQL versions below 5.6.4 lack millisecond precision, so event ordering can become unreliable for an auditor. The platform team confirms the engine version, the database type and version, and that timestamp columns keep the precision the evidence needs. Done when the team holds a written record of these facts for each environment.
Set the history level for audit detail
Choose the history level in the engine configuration that captures the activity an auditor will ask about, such as who started instances, who completed tasks and when variables changed. Confirm the level names and what each level stores in the documentation for your Flowable version, since option names and defaults can differ between major versions. Engineers set the level per environment, deploy a test process and check that the history tables hold the expected rows. Done when a test task completion appears with its user and timestamp.
Configure event logging for engine activity
Enable event logging for the engine events your control set requires, and direct them to a store that application users cannot edit. Event logging is configured separately from history, so confirm how your version registers the event listener and whether each entry includes the actor and the process reference. Define the fields each event type must carry, then trigger one event of each type in a test environment. Done when every required event type appears in the log with an actor, a time and a process reference.
Route application logs through the host framework
Send delegate, service task and integration errors to the logging framework your Java application already uses, using one consistent format. Put process instance and task identifiers in every entry so application lines can be joined to engine history. Confirm the logging library, the field names and the diagnostic context support against your Flowable version and your Spring Boot baseline. Done when a forced exception in a test delegate produces one entry with the instance identifier and reaches the central log collector.
Set retention and deletion rules
Write a retention period for history, event logs and application logs, based on the records your organization must keep and the obligations that apply to them. Set the cleanup schedule in Flowable and in the log platform to match, and agree with compliance that no cleanup runs against records needed for an open audit or legal hold. Confirm how your version's history cleaning works and exactly what it deletes. Done when a retention table lists each store, its period, its owner and its cleanup job, and a test cleanup removes only expired records.
Restrict access to history and log stores
Limit read access to the history tables, the event log and the log platform to the roles that need it, and separate the administrators who run the engine from the reviewers who check evidence. Restrict write access to audit stores to the logging pipeline. Check engine REST access and database accounts against your identity model, since those paths can change records outside the application. Done when an access review lists who can read, change or delete each store, and a test account without the review role is refused.
Test a sample extraction end to end
Run an extraction the way an auditor would sample. Select a set of process instances, export their history rows, event entries and matching application log lines, and check that timestamps, actors and identifiers line up across the three sources. Save the query and its output as a repeatable procedure, and record a checksum for each export if your team uses one. Repeat the test after each Flowable upgrade or configuration change. Done when a reviewer who did not set up the logging reproduces the extraction from the written procedure.

What Flowable does not cover for ISO 27001 logging and records

Flowable records what happens inside a process or case, but several requirements under A.8.15 and A.5.33 sit outside the engine. The cards below list the work your organization keeps, and the decisions your team should document before an auditor asks for samples.

Log analysis and alerting

A.8.15 asks that logs are analyzed, not only produced and stored. Flowable writes history and job failures to the database and application logs, but it does not review them or raise alerts on unusual patterns such as repeated failed jobs, unexpected cancellations or deletions of instances. Define which events someone reviews, how often, and who records the outcome. Confirm that your log platform receives Flowable application logs and that alert rules exist for them.

Protection of log stores from administrators

The engine can write history rows, but it cannot stop a database administrator from editing or deleting them. A.8.15 expects log information to be protected, and the control covers administrator and operator activity as well. Restrict write and delete rights on history tables and log destinations, forward logs to a store that application administrators cannot change, and confirm who can alter the database schema.

Backup and recovery for records

A.5.33 asks that records are protected from loss and destruction. Flowable does not back up its own database, and it cannot prove that a restored database still contains complete history. Plan database backups that include runtime and history tables, test restores on a schedule, and document how a recovered history is checked against the state of the system before the incident.

Centralized time synchronization

Audit records are only useful when timestamps agree across the engine, the application server, the database and the log platform. Flowable stores timestamps from the host and database clock, and MySQL versions below 5.6.4 lack millisecond precision. Set one time source for all nodes and databases, record the time zone, and confirm that event ordering across nodes can be reconstructed from your logs.

Retention policy decisions

Flowable keeps history according to the history level and cleanup jobs you configure, but the retention period itself is a business and legal decision. Decide how long process and case records, logs and approval evidence must remain, who approves that period, and how deletion is scheduled and documented. Check that cleanup does not remove records still needed for an open audit or dispute.

Authorization checks in the application

Flowable does not decide who may start, claim or complete a task on your behalf unless your application or identity service enforces it. Records protected under A.5.33 are only as trustworthy as the identities behind them. Map roles to task actions, reject completions by unauthorized users, and sample audit history to confirm that each completion carries an identity your access model recognizes.

Who owns each logging control in cloud, data center and air-gapped setups

In a cloud deployment, the provider runs the physical facilities and underlying hardware, but your organization still owns the logs and history that Flowable writes into your database, your log pipeline and your storage buckets. Control A.8.15 asks that logs are produced, stored, protected and analyzed, and the cloud account is where most of those promises are kept or broken. Confirm which parts are managed services and which are self-run, because that changes who can answer for each log.

Log storage: Decide whether Flowable application logs go to a managed log service or to a store your platform team operates, and confirm who holds the keys and retention settings for that store.
History table backups: Confirm whether the managed database snapshots include the Flowable history tables, how long snapshots are kept, and who can restore them.
Account-level audit trails: Confirm that control-plane activity (role changes, key use, storage policy edits) is recorded and retained outside the account it describes.
Access reviews: Assign a named owner for reviewing cloud IAM roles and database users that can read or change history, and confirm how often that review runs.
Shared responsibility gaps: Ask the provider which log sources it retains for you and for how long, and which ones disappear unless you export them.

Confirm each item with your cloud platform team and check the provider's shared responsibility documentation for your services.

Questions buyers ask about Flowable and ISO 27001 logging

Does running Flowable alone satisfy ISO 27001 control A.8.15 Logging?

No. Flowable is one input to A.8.15, which asks that logs of activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed across the systems in scope. Flowable history, event logging and application logs cover the process layer, but the database, operating system, identity provider, API gateway and the applications around Flowable also produce evidence. Your organization still needs a documented logging scope, a defined review process and an owner for the ISMS. A mapping shows which Flowable records answer which parts of the control, and where gaps remain that other systems must close.

What drives the effort of a Flowable logging mapping?

The main drivers are the number of process and case definitions in scope, the history level configured in each engine, the number of integrations that create or change process data, and whether logs already flow into a SIEM. More processes and integrations mean more event sources to map and test. A higher history level records more data, which changes what an auditor can sample and how much retention you must manage. An existing SIEM can reduce build work, but it also raises questions about log formats, field consistency and forwarding. Ask any partner for a written scope that lists each of these items and the systems that receive the logs.

What does the client team need to provide for this work?

Expect to provide access to non-production and production-like environments, configuration files and deployment pipelines, a sample of real workflow records with the right data handling approvals, and named contacts for the ISMS, security operations and the business owners of each process. The team must also decide the retention periods for history and logs, who may read them, and which auditor questions are in scope for the review. Retention and access decisions belong to your organization, not the implementer. Confirm in writing who signs off each decision and how long those reviews take in your change process.

Can an internal team map Flowable logging to A.8.15 without outside help?

Often yes, if the team has Flowable engineering skills, an understanding of the ISO/IEC 27001:2022 Annex A controls and the authority to change logging configuration. The work is largely analysis and documentation, plus testing that the chosen history and event settings produce the records you claim. Internal teams often struggle with objectivity, time for cross-team coordination and knowing which auditor sampling methods will apply. A common split is to keep ownership internally and bring in an outside implementer for the Flowable configuration and test evidence. Compare both options against the same written scope before deciding.

How does the certification cycle affect when this work should happen?

Plan the mapping around your audit calendar, not the vendor's release schedule. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. Your certification body will sample evidence during those audits, so logging changes should be in place, tested and documented before the next audit window. IAF MD 26:2023 also set the end of the transition from ISO/IEC 27001:2013 to 2022 as 31 October 2025, so confirm with your certification body which edition applies to your certificate. Ask your certification body which dates matter for your certificate.

Does DeployOpen issue an ISO 27001 certificate for our Flowable logging?

No. DeployOpen plans, implements and documents systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent accredited certification bodies perform the audit and decide whether your ISMS meets ISO/IEC 27001. ISO itself does not certify organizations. A DeployOpen engagement can prepare the Flowable configuration, mapping and sample evidence that your certification body will review, and it can document how those records are protected from loss and unauthorized change under A.5.33.

What should we ask for in a written scope before starting?

Ask for a list of processes, cases and integrations in scope, the history level and event logging settings for each engine, the log destinations and retention periods, and the controls each log is mapped to, including A.8.15 and A.5.33. Also ask for the test cases that prove each record is produced and protected, the named responsibilities for every decision, and the deliverables with acceptance criteria. Good scopes state what is excluded, such as systems outside Flowable that you will handle separately. Most engagements of this kind are fixed-scope, so the written scope is the basis for both the quote and the timeline.

What the auditor samples and what fails the sample

An auditor working inside the three-year ISO/IEC 17021-1 certification cycle, with at least one audit in every calendar year, usually tests logging by working backward from a sample. The auditor picks a set of records, such as completed approvals, changed decision tables or exported case data, then asks the organization to show where each record's history lives, who could read and change it, how long it is kept and what the logs say about exceptions and failed jobs. Each step maps to A.8.15 Logging or A.5.33 Protection of records. Before the audit, confirm which Flowable process and case definitions are in scope, which history level each one runs at, and whether the sampled records can actually be produced from the history tables and your log store without a manual rebuild.

Most failures appear at the edges of that sample. A process that was deployed with history turned off, or a case model added after the logging configuration was set, leaves gaps that look like missing evidence even when the engine behaved as designed. Exports are a second weak point: a CSV of task history pulled into a spreadsheet, a dashboard query run by an administrator, or a support extract sent by email may carry the same data without the access restrictions, integrity checks or deletion rules that the original tables had. A third pattern is undocumented retention. If the team cannot state how long runtime and history rows are kept, which cleanup jobs run, and who approved the schedule, the auditor will treat the retention as unmanaged, even if the database is configured sensibly.

Plan for these failures before the sample is drawn. Keep a register of every deployed Flowable definition with its history setting and owner, test that a sampled instance can be traced from the approval step to the user identity and timestamp, and restrict export paths to the same roles that can read the history. Write the retention rule as a controlled document that names the cleanup schedule and the person accountable for it. Ask your auditor early which records they intend to sample, because a clear answer to that question shapes most of the preparation.

How DeployOpen scopes and delivers ISO 27001 logging evidence for Flowable

DeployOpen plans, implements and documents Flowable logging for ISO 27001 A.8.15 and records protection inside your own infrastructure, starting from a written scope. The work covers history configuration, application logging, retention settings and the evidence packs your team can show an auditor.

How we scope

Engagements are fixed-scope, with the Flowable engines, environments and log sources agreed in writing first.
We map which history, event and application log sources feed A.8.15 and which store records under A.5.33.
Scope defines the retention periods, access roles and sample evidence your auditor is expected to request.

How we build

We configure history levels, event logging and MDC log fields on the Flowable engines in your environment.
We set up protected storage, access controls and retention for history tables and log destinations.
We test that a sample process instance produces the records, fields and protections the written scope requires.

How we hand over

You receive a control mapping document linking each Flowable log source to the relevant Annex A control.
Runbooks describe how to pull, verify and export logs and history records for an auditor sample.
Documentation records configuration, retention decisions and open items your compliance lead must confirm.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover re-checking logging configuration when Flowable versions or environments change.
Your compliance and audit teams remain responsible for certification decisions, which independent bodies make.