Configuring Ignition for Part 11 Compliance

May 27, 2019
Like many other SCADA platforms, Inductive Automation’s software is compliant with Part 11 requirements. Here’s what you need to know about setting it up correctly.

21 CFR Part 11 (Part 11) establishes U.S. Food and Drug Administration (FDA) regulations on electronic records and signatures. In the pharmaceutical world, some of the first questions we get asked is: “Is it Part 11 compliant? And does it provide data integrity?” In this article, we will examine Part 11 compliance and capabilities Inductive Automation’s Ignition software.

Ignition is a cross-platform supervisory control and data acquisition (SCADA) tool that is useful for building applications such as reporting systems, data dashboards and human-machine interfaces (HMIs). Like many other SCADA platforms, it is compliant with Part 11 requirements, with available features like audit trails and user management. These features are built in to the Ignition platform and can be customized with minimal, thoughtful setup to ensure compliance.

The acronym ALCOA—which stands for attributable, legible, contemporaneous, original and accurate—is often used to abbreviate the FDA guidance framework on data integrity. Ignition provides features that allow all these requirements to be met.

Data storage

Ignition interacts with SQL databases for the historian module and audit trail. To ensure data integrity of SQL databases, logins and permissions must be strictly configured for each database. An exclusive account should be configured for Ignition to connect to SQL with read/write access. No other user should have write access because this would allow tampering with historical and audit trail data.

Other users can be configured with read access to databases for querying data. However, any validated data provided by the system should be presented as read-only reports. Tools and controls are available within Ignition for creating displays to review data, such as trend charts and customizable tables. Tools are also available to generate reports to be printed or exported in read-only formats like PDFs.

Security can be applied to tags, user interface components, projects and the Ignition Gateway. These security settings ensure that only authorized users can read or write to tags, interact with user interface components like buttons and text boxes, or modify validated configurations. User accounts and roles are key to configuring this security.

User management

Ignition provides several methods to manage users and roles, including options for local management (contained within Ignition), Windows Active Directory and hybrid options. In most cases, managing users through Active Directory is the best approach for regulatory compliance.

Active Directory can be set up to grant access to users with their own existing username and password from the corporate Active Directory. This helps ensure that all users are uniquely identified throughout the corporation. This also ensures that the credentials of each user are held to the standards and policies enforced for the domain. Users can also be centrally disabled or removed without having to update each individual application they had access to.

Roles can be configured to ensure only authorized users access specific sections of an application. When configuring an application in Ignition, these roles are referenced by configuring security properties or using scripting to lock out unauthorized users from accessing parts of the application. For example, acknowledging alarms could be disabled for users lacking specific roles.

Audit trail

Ignition provides an audit trail to record data contemporaneously, audit profiles are created and the retention period for the audit profile is set so that data is never deleted. By default, Ignition will record a timestamp, username, computer name and details about each audited action. Default audited actions include tag writes, SQL commands (update, insert, delete), project changes from the Ignition Designer, and user login/logout events. Because the audit trail information is stored in a SQL database, the default audited actions can be extended. During any scriptable event (for example, clicking a button to switch a system from auto to manual mode), a SQL insert query can be configured to add an event to the audit trail.“Done by” and “checked by” information can be easily added to every scriptable event and the audit trail.

Any Ignition project can be made compliant with Part 11 requirements by applying some best security practices and leveraging the tools and features available in Ignition. If not designed from the start, these features can be implemented over time. Whether a project requires compliance or not, it is never a bad idea to evaluate the security and data integrity of your systems and applications!

Josh Stauffer is a lead engineer at Panacea Technologies, a certified member of the Control System Integrators Association (CSIA). For more information about Panacea, visit its profile on the Industrial Automation Exchange.

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...