Data Confidentiality in Organizations in the Context of Action Audit

Recently, during one of the presentations, I was asked about data confidentiality in Action Audit. In response, I immediately began discussing the mechanisms, procedures, and safeguards we use to ensure the highest standards of data security for information stored in the system by clients. However, this question was about something different: access to data by representatives of the same organization.

I must admit I was delighted by this question because the area of information access management in Action Audit has always been treated as a priority and has been a cornerstone for developing subsequent business functionalities. From the very beginning, we designed the system assuming it would be used by organizations with complex structures where not everyone should be able to see to modify all the data.

In this article, I will discuss the key elements of the system that influence the visibility and level of access to data by users.

This article, due to the used terminology and the described algorithms, is primarily aimed at current system users, but I’ve tried to write it in a way that’s also understandable to readers who haven’t yet interacted with Action Audit. I invite everyone to continue reading.

Organizational Structure

The organizational structure implemented in Action Audit is the foundation for configuring the system. It allows you to reflect the actual organizational hierarchy of a company within Action Audit.

When building the structure, it’s worth considering how detailed it should be and how deep should it go. Should you replicate the approved organizational chart exactly, model it less specifically, or the opposite, expand it by adding organizational units not present in the chart, such as production lines and work centres? There’s no single correct approach, and every organization must develop the best method for itself. From observations, the most common approach is to “drill down” to the department or division level while excluding individual production lines or workstations from the structure.

How Does the Structure Impact Data Access?

The example organizational structure of a production plant, highlighting several departments, is presented in the graphic below. Additionally, the production department is divided into four areas.

By assigning individuals to organizational units, you ensure that a given user will see data from their organizational unit and all subordinate units. For example, a person assigned to the top-level unit (e.g., Rudolph Morgan Ltd.) will have access to data from the entire organization, while individuals in the Extrusion Area will only see data from that area.

The organizational structure does not determine how a user can manipulate the data, only what pieces of data they can see in the system.

Roles and Permissions

Roles and their associated permissions define the operations a user can perform on the data available to them based on their position in the organizational structure. Simply put, roles determine whether a person can: view data, edit data, delete data.

The documentation includes a page describing roles and permissions in detail, so I’ll skip this topic and focus on the next one: access to action plans.

Access to Action Plans

The specifications described in this section apply to general action plans and similar objects such as audits, Kaizen ideas, near-miss events, and engineering changes. The features and mechanisms determining access are most visible and accessible in the action plan view, so I’ll focus on plans in this discussion.

A user’s access to (view) an action plan depends on:

• Their position in the organizational structure,
• Being assigned as the owner of the action plan,
• Being assigned responsibility for at least one activity,
• Being responsible for a related resource (e.g., Audit or Kaizen idea),
• Being assigned as a participant, either directly or via a user group,
• Being the person who created the plan.

As you noticed, multiple factors influence whether a person can see an action plan. This is because many scenarios in an organization require a user to participate in an action plan.

Position in the Organizational Structure

The mechanism described in the "Organizational Structure" section also applies here. A user has access to all objects assigned to their organizational unit and its subunits. This assignment doesn’t specify whether the access is full or read-only.

Assigned as Action Plan Owner

The owner of an action plan has full read and management access to the plan. Period. :)

Assigned Responsibility for an Activity

A person responsible for at least one activity in the plan has access to view the entire plan, including its structure, comments, attachments, and details of other activities. This ensures they understand the full context of their task and have access to all materials and information that may help them.

Responsibility for a Related Resource

In Action Audit, two-stage processes are available, where the second stage depends on fulfilling conditions in the first stage. Examples include:

• Audit and Post-Audit Action Plan if the audit identifies at least one nonconformity,
• Kaizen Idea and Improvement Implementation Plan if the idea is deemed worthwhile,
• Near-Miss Event and Safety Measures Plan if the event is appropriately classified,
• Evaluation and Engineering Change Implementation Plan if the change is justified.

In these cases, the person responsible for the first stage (e.g., an auditor) gains access to the resulting action plan (second stage). This principle also works in reverse.

Assigned as a Participant

Assigning someone as a participant, either directly or through a user group, grants access to the action plan regardless of organizational structure and other factors.

Action Plan Creator

The person who creates an action plan initially gains full access to it, as they are automatically assigned as a participant with write permissions. This allows the creator to expand the plan, but their assignment can be removed at any time.

A typical scenario is when a department or division manager designates someone to input action plans into the system while retaining ownership of the plan. The manager can later remove the creator’s assignment, transferring full control.

Conclusion

Managing data confidentiality in an organization is no simple task. The multitude of rules and mechanisms in Action Audit that define access principles reflects the complexity of this issue. However, after years of development, countless approach adjustments, and hundreds of user meetings, we believe we’ve created an optimal model for user access to data.

I can now confidently state that in Action Audit, every user sees the data they’re supposed to see and does not have access to data they shouldn’t see.

These processes are designed to ensure security and align with real-world organizational workflows, making Action Audit effective for companies across various industries.