Audit trails and regulatory compliance

To achieve compliance in regulated industries, the plant might be required to keep records that answer these questions:
  • Who performed a particular operation on a specific resource?
  • Where did the operation occur?
  • When did the operation occur?
  • Who approved the operation?
To answer these questions:
  • Ensure that all users are uniquely identifiable in the system
  • Keep a record of deleted users
  • Log information about user and system activity to diagnostic log files
  • Set up audit trails of successful or unsuccessful attempts at modifying system values
Ensure that all users are uniquely identifiable in the system
When choosing usernames, ensure that they are unique.
  • A user should have the same username on every computer. This is mostly for convenience, both for the user and for the administrator.
  • A particular username should always refer to the same person. A system in which the same username refers to more than one person is never really secure.
Develop a scheme for identifying users uniquely. Keep in mind that usernames are visible, and should not contain any private information, for example, social security numbers. usernames are also typed frequently, and should be relatively easy to remember.
If the system is required to comply with governmental regulations, multiple names for the same user may be necessary. This may occur if a user leaves the company and their user account is deleted, then the user is rehired.
Keep a record of deleted users
To ensure that all user accounts remain unique, keep track of deleted accounts. This might also be an audit requirement, such as tracking a user's actions throughout the system, even after the user's account was deleted.
To ensure that only unique user accounts are created, enable the security policy
Keep record of deleted accounts
. To avoid a trial-and-error process of creating unique user accounts, make deleted accounts visible in lists of users by enabling the security policy
Show deleted accounts in user list
.
Log information about user and system activity to diagnostic log files
Logging information consists of two steps:
  1. Choose the information to log and then send the information to
    FactoryTalk Diagnostics
    . For example, enable audit logging to record what changes were made to security policies or other objects, who made the changes, and when they were made. If the
    Audit configuration and control system changes
    policy is not enabled,
    FactoryTalk Diagnostics
    does not receive any audit messages, and cannot store the audit messages in log files.
  2. Configure
    FactoryTalk Diagnostics
    to store the information in log files. For example, configure
    FactoryTalk Diagnostics
    to store audit information for Operators in local log files. If this step is not completed,
    FactoryTalk Diagnostics
    receives the chosen information sent to it, but does not capture this information to store in log files.
To configure
FactoryTalk Diagnostics
routing and logging options, select
FactoryTalk Diagnostics
Setup
from the
Tools
menu on each computer where the
FactoryTalk Administration Console
or
FactoryTalk View
is installed. To view diagnostic messages, from the
Tools
menu, select
FactoryTalk Diagnostics
> Viewer
.
Set up audit trails of successful or unsuccessful attempts at modifying system values
The most common type of auditing activity is recording failures. This helps trace failures, and isolate and correct their causes.
In some industries it is also common, or mandated by law, that certain types of successful user activity is audited. For example, when making pharmaceutical drugs, any changes or adjustments in recipes must be recorded. Recording this activity allows any problems that might occur to be traced to a specific batch of the product.
Auditing object access success or failure is controlled by system-wide audit policies. Enable these policies if the plant requires them. Audit information is sent to
FactoryTalk Diagnostics
. Use the
FactoryTalk Diagnostics
Viewer to monitor security-related events.
Provide Feedback
Have questions or feedback about this documentation? Please submit your feedback here.
Normal