You may be using the correlator persistence feature, in which the correlator periodically takes a snapshot of its current in-memory state and saves it on disk. Most of the correlator's in-memory application state that contains personal data will therefore be included in the persistence datastore. There are a few exceptions: state in non-persistent monitors and in-memory stores will not be included. See also Using Correlator Persistence.

It is important to protect this personal data at rest by setting appropriate permissions on directories where datastore files will be written to ensure only the correlator process (and authorized system administrators and backup processes) have access to it. On Windows, this would mean setting an inheritable Access Control List (ACL) limiting read access to the contained files. On UNIX systems, this would involve restricting read and execute permissions to only the owning user (that is, 700) and if possible also setting a umask of 0077 on the correlator process to ensure files created by the correlator also have locked down permissions.

There is no need to implement rectification or erasure, since the persistence store is intended for access only by the correlator, and any rectification or erasure operations performed on the main correlator state will be automatically replicated into the persistence datastore within a very short time.

There is an additional datastore used to hold recently received JMS messages when reliable correlator-integrated messaging for JMS is used. See XML configuration bean reference for details about how to configure the reliableReceiveDatabase location. The same considerations apply as for the persistence datastore - rectification and erasure are not necessary as only recently received messages are retained, and the datastore should not be read by any process other than the correlator. In the case of AT_LEAST_ONCE receivers, messages are retained only until they have been acknowledged by the correlator. In the case of EXACTLY_ONCE receivers, unique message identifiers (uniqueMessageId) may be retained for longer in order to avoid duplicates (see Duplicate detection when using JMS for details) but this should not have any privacy implications, provided user identifiers are not used in the message identifiers.