Production Management System Access Control – Roles, Approvals, Audit Logs

Production management system access control is one of those areas that gets set up as “everyone has every permission for now” during go-live and then sits untouched for years. It resurfaces all at once as an audit finding, a leaver whose account still works, or an operator who both enters and approves the same order. This article walks through role design, approval workflow design and operation-log auditing for Japanese-affiliated factories operating in Thailand.

Why production management system access control is being asked about now

The go-live shortcut that never gets undone

When a production management system or an MES goes live, the overriding priority is that production does not stop. In the final weeks before cutover, someone somewhere cannot see a screen they need every single day. The fastest way to clear that queue is to grant everyone administrator-equivalent permissions.

As a go-live decision that is not necessarily wrong. The problem is that the temporary state becomes permanent. Once operations settle down nobody raises permissions again, the vendor’s default roles stay as shipped, and every new joiner is set up “the same as their predecessor”. Three years later, nobody in the company can explain why any given person holds the rights they hold.

In Japanese-affiliated factories in Thailand this pattern is sharper still. The IT function is often one person, or someone who also handles general affairs or accounting, and permission design is exactly the kind of work that nobody misses while it is stalled. On top of that, local staff move roles and change employers more frequently than in Japan, so accounts turn over constantly while the process for handling them stays informal.

Audit season brings it all to the surface

The moment this surfaces is almost always an audit. Internal audit from the Japanese head office, a parent-company controls assessment, an ISO surveillance visit, a customer audit. Whichever it is, the questions about systems are broadly the same.

• Can you produce a list showing who currently holds which permissions
• Can you show the basis on which each permission was granted, meaning the request and the approval record
• Can you show when leavers and transferred staff had their access removed
• Can you say how many privileged accounts exist and who uses them
• Can you trace who performed a critical operation and when

Being unable to answer any of these is not unusual in practice. The awkward part is that remediating after a finding costs far more than doing it in peacetime. Findings come with deadlines, and you end up running a permission inventory, a role redesign and a logging project in parallel inside three months, without stopping production, when six unhurried months would have done.

The biggest risk is misuse of legitimately granted access

Before external attackers, the case to understand is legitimate permissions being used through a legitimate login. The clearest published example of exactly this failure mode is the incident Recruit disclosed on 30 March 2026.

According to the company’s disclosure, a former employee used access permissions granted to them for their work to take internal data out to a third party outside the company. The company received an external tip in December 2025 and confirmed the facts through an internal investigation in February 2026. Roughly 20,699 people were affected, a figure that includes 32 executives, 24 executive secretaries, 449 sales staff in the beauty division, records covering approximately 19,000 employees in total, and 1,194 club-activity leaders.

What this shows is that firewalls, endpoint detection and multi-factor authentication do nothing against this pattern. The credentials were genuine and the permissions were genuine, so to the system the activity was indistinguishable from ordinary work. Only two things can draw that distinction. One is the permission design itself, which decides whether this person ever needed reach to that data. The other is the operation log, which records who viewed or exported what, when, and how much of it.

External attacks are also a question of how far an intruder can reach

External attacks obviously still matter. On 14 August 2026, Nichirei disclosed that a ransomware attack on 13 July 2026, attributed to the RansomHouse group, may have leaked employee names, dates of birth, company email addresses and human-resources information. In the same month of August 2026, several other companies, Chubu Electric Power among them, reported unauthorised access to internal systems.

Where access control earns its keep against external attacks is after the perimeter has been crossed. The credentials an attacker captures first usually belong to an ordinary end user. What determines how far those credentials reach is precisely the permission design. If everyone can reach every module, compromising one low-level account is the same as compromising the entire dataset. If data scope is restricted per role, the damage stops at that account’s own working area.

Operating in Thailand adds the weight of PDPA

Companies based in Thailand carry one further consideration, which is that enforcement of the Personal Data Protection Act is genuinely active. According to an analysis published by Tilleke and Gibbins on 1 August 2025, Thailand’s PDPC published 5 cases carrying 8 fines, totalling roughly 21.5 million baht. The principal causes cited were security measures that were inadequate or had never been reviewed, failure to meet breach-notification obligations, and failure to appoint a data protection officer.

“Security measures that had never been reviewed” is an access-control statement. A role model designed once and left untouched for years, or leaver accounts that still function, land squarely inside that finding. A factory production management system holds attendance records, work results and skill data for employees, plus contact details for customer and supplier staff. All of that is personal data. The wider picture of PDPA obligations seen from the factory floor is set out in personal data protection for factory IoT, which is worth reading alongside this article.

Designing business system access permissions in three layers

Tying permissions to job titles always breaks

The usual starting point for permission design is the org chart. Managers get this, supervisors get that, general staff get the rest. It looks tidy and it fails early, because a production control manager and a quality assurance manager need entirely different rights despite holding the same grade. Exceptions accumulate one by one, and within a few years the relationship between title and permission has dissolved.

A design that survives does not try to express permissions on a single axis. It separates them into three independent layers – role, which is what work the person does, scope, which is how much data they may reach, and action, which is what they may do to it.

Layer 1 – role, defined by the shape of the job

A role is defined by the work, not by grade or department. For a production management system the useful units look like this.

• Order intake and requirements calculation
• Production planning
• Shop-floor result entry
• Inventory and goods movement
• Purchasing and ordering
• Quality record entry
• Cost and performance analysis
• Master data maintenance
• System administration

The important property is that this list is derived from the work that has to happen, not from the people currently in the building. One person holding three roles is unavoidable at small and mid-sized plants. What matters is that the situation is visible as “this person has been assigned three roles” rather than hidden inside a bespoke blended role. Create a custom hybrid role and nobody will know what happens when that person transfers.

Layer 2 – scope, restricting the reach of data

Two people can hold the same role and still need different data. In a company with several plants and lines, this layer is where real information control happens.

• Site or plant (a Rayong plant user does not see Chonburi results)
• Line or process
• Product family or customer (one account manager does not see another customer’s drawings or costs)
• Time period, meaning how far back historical data can be read

Scope control is where products differ most in real capability. Every system can define roles. Whether the same order entry screen can show only the orders belonging to the customers a person handles is a much harder question, and one to confirm explicitly during selection.

Layer 3 – action, separating what can be done

The third layer is the type of operation. If a system can only express “read” and “write”, treat its access control as weak. Practically, you need at least these five.

The one most often overlooked is the last. Because a person with view rights can already see the data on screen, exporting is treated as equivalent. In control terms the two are nothing alike. Reading records one at a time on screen and downloading the entire table as CSV differ by orders of magnitude in risk. If the failure mode you are guarding against resembles the exfiltration case above, bulk export must be carved out as its own permission and pushed into the operation log discussed later.

Segregation of duties – combinations that must not sit with one person

Once the three layers are drafted, check them against segregation of duties. In IT general controls practice, the standing example is that the same person must never hold both the right to create purchase orders and the right to approve payments. If the person who created it can approve it, the approval step means nothing.

Translated into a production management system, at minimum the following combinations deserve separation.

• Creating a purchase order and approving that purchase order
• Recording goods movements and adjusting stocktake variances
• Entering shipping instructions and confirming shipment results
• Changing item master prices and approving costing results
• Performing ordinary business operations and deleting or reconfiguring the operation log

The last one deserves particular attention. If the person who can erase the log can also perform business operations, the audit trail itself cannot be relied on. Even system administrators should sit in a configuration where they cannot alter log records.

At a small plant, full separation is sometimes physically impossible. The right response is not to give up but to document the fact that separation is not achievable and put a compensating control in its place. A compensating control might be logging every instance of the operation and having a manager review the list monthly. What an audit asks is not whether separation exists, but whether the risk was recognised and addressed.

Design patterns for approval workflow systemisation

Do not copy the paper approval route

The most common failure when systemising approvals is transplanting the current paper circulation route onto a screen. Paper routes tend to accumulate stamp boxes that serve as a mix of notification and accountability, and copying them wholesale produces a backlog of pending approvals. Wherever a backlog appears, the shop floor invents a workaround. They ship first and fix the system afterwards. At that point the approval records in the system no longer describe reality, and the control has become decorative.

Before systemising, break down what each stamp actually guarantees. In most cases it is one of three things.

• Verification, meaning someone checked that the content is correct
• Approval, meaning a decision that the action may proceed
• Notification, meaning someone who needs to know has been told

Only the middle one belongs in a system approval step. Notification is served by a notification feature, and verification can frequently be replaced by input validation or a checklist at entry time. It is common for a decision that carried five stamps to reduce to one approval step and three notifications.

Narrowing down which operations need approval

Put approval on everything and the operation seizes up. Put it on nothing and there is no control. Three axes make the decision workable.

Everyday operations that meet none of the three, ordinary work-result entry for instance, do not need approval. Put approval there and approvers will start bulk-approving without looking, which lowers the credibility of every approval record in the system.

Design delegation and escalation from the start

The single biggest cause of approval workflows collapsing is the absent approver. Business trips, leave, resignations, transfers. Leave this until later and the shop floor eventually arrives at the worst possible workaround, which is borrowing the approver’s ID and password. From that moment the approval records and the operation logs both lose meaning.

Put these three into the specification from the beginning.

• Delegates can be registered in advance, and the fact that an approval was made as a delegate is recorded in the log
• Items left unapproved beyond a set period escalate automatically to a higher approver
• When an approver resigns or transfers, their pending items can be handed over to a successor in bulk

The third is routinely neglected, and without it every approver transfer strands a set of unprocessed items in limbo.

Put ID issuance itself through an approval workflow

What gets missed is that approval workflow is needed not only for business data but for the granting of permissions themselves. IT general controls practice describes ID issuance as a standard sequence – a submitted request form, approval by the requester’s manager, and approval by the IT department. The point is that approval is deliberately two-stage. The manager judges whether that permission is needed for that job. The IT department judges whether the permission is technically and structurally appropriate. The two stages judge different things, so neither one alone is sufficient.

Very many companies handle this verbally or over chat, but what an audit requires is a record. You do not need a dedicated workflow product. A request form plus a retained approval history is enough to begin with, even on existing groupware. What matters is being able to show, one permission at a time, when it was granted and on whose approval.

The operating cycle for internal control over production management systems

Quarterly access rights review

Access control is not a design exercise that ends. It becomes a control only when paired with periodic review. IT general controls practice sets quarterly access rights review and attestation, meaning confirmation of appropriateness and sign-off, as the standard cadence.

In practice the steps are these.

1. Export the current permission list from the system
2. Send each department head their own list and have them mark permissions that are no longer needed
3. Reconcile against HR data to catch leavers and transferred staff still present
4. Review privileged accounts and system administrator rights individually
5. Record the resulting deletions and changes, and retain the record until the next review

Whether this is realistically sustainable depends almost entirely on step one, meaning whether a permission list can be exported at the press of a button. In systems where extracting that list requires a vendor request, a quarterly inventory will never become habit. Confirm self-service export of the permission list during product selection.

Trigger on joiners, leavers and transfers

The quarterly review is a safety net, not the first line of defence. A leaver whose account survives for up to three months is not an acceptable outcome. The first line is processing driven by HR events.

• Resignation – suspend all accounts on the last working day. Suspend rather than delete, so that log traceability is preserved
• Transfer – remove the old permissions before granting the new ones, rather than adding on top
• Extended leave – suspend temporarily and re-confirm on return
• Contractor staff rotation – manage individually rather than by contract

None of this works without a register of who holds which account and which device. How to systemise the inventory of accounts and equipment is covered in IT asset management for factories, and it is worth building at the same time as access control.

Running this when there is effectively no IT department

Everything above may read as if it assumes a dedicated IT department. Most Japanese-affiliated factories in Thailand run the IT function with one person, or as a secondary duty. Executing a quarterly review in that situation is, honestly, not easy.

Three realistic options exist. The first is outsourcing only the inventory work while keeping the judgement inside. The laborious parts, exporting, reconciling and writing up, go outside, and department heads decide only what to remove. The second is building an annual or semi-annual access review into the system vendor’s maintenance contract. The third is externalising the IT function itself, and the decision criteria for that are set out in IT department outsourcing. In every case, keep the final approval decision inside the company. Move that outside and the ownership of the control becomes unclear.

An operation log and audit trail checklist for factories

What has to be recorded

Operation logs are not judged on whether they exist but on whether they are usable in an audit. A single log record needs at least these five attributes.

The before and after values are the attribute most often missing by default. It is extremely common to find login history and screen access history being captured while the actual data changes are not retained at all. For master changes and retroactive result edits in particular, confirm individually that the configuration keeps the prior and new values.

Narrowing what gets logged

Logging every operation produces a volume nobody ever looks at. For a factory production management system, the priority scope is this.

• Logins, logouts and authentication failures
• Granting, changing and removing permissions and roles
• Master data changes covering items, prices, business partners, bills of material and standard costs
• Approvals and rejections
• Period close, retroactive result edits and stocktake variance adjustments
• Bulk data export and extraction, including API access

The last item is the direct countermeasure to the exfiltration risk described earlier. If you retain who exported which range of data, when, and how many records, an abnormal extraction can be found afterwards. Without it, an exfiltration cannot even be known to have happened.

Retention period and tamper resistance

There is no single correct retention period, but there is a method for deciding one. Start by working back from your own audit cycle and set the floor at a length that reliably covers the most recent audit period. Then align to the longest of the parent company’s document retention policy, the retention practice for tax and accounting records, and any period required by contract. At an absolute minimum, avoid the state where logs auto-delete after a year and the previous audit period no longer exists.

For tamper resistance, cover three points. First, configure the system so that business system administrators cannot edit or delete logs. Second, replicate logs daily to separate storage where the business side holds no write permission. Third, log the deletion and configuration-change operations themselves. Only with all three present does a log function as an audit trail.

A log nobody reads is not an asset

The recurring problem with logs is that they are collected and never read. In the PDPC enforcement cases noted earlier, failure to meet breach-notification obligations was among the causes cited. Notifying requires noticing first, and noticing requires someone actually looking at logs.

A workable routine mixes frequencies. Review the permission-change list monthly. Check bulk export and API access counts weekly, following up only on figures well outside the normal band. Alert in real time on repeated authentication failures and account lockouts. Not everything needs to be reviewed daily, and separating cadence by subject brings the workload down to something sustainable.

What to look at when selecting or configuring a system

Questions to put in the RFP

Access control is an area where retrofitting after go-live is often impossible by product design. That makes it a selection-stage question. Putting the following into the request for proposal exposes the real capability gap between suppliers.

• Can role definitions be created and changed in-house, or is vendor work required
• Can a single user be assigned multiple roles
• Can access be restricted by data scope such as site, line or customer
• Can view and export, meaning CSV, reports and API, be separated into different permissions
• Can the permission list be exported by our own staff, and in what format
• Can approval routes and conditions be configured in-house, and are delegation and automatic escalation available
• Does the operation log retain before and after values, and can the logged operations be chosen
• What is the log retention period, and what mechanism exists for transfer to external storage
• Can the system be configured so that administrators cannot edit or delete logs

How to get requirements like these into a request for proposal without gaps is covered end to end in the production management system RFP guide, which is worth reading first if selection is imminent.

Practical moves when the existing system is weak

If a system already in production has inadequate permission features, replacement is not the only answer. Staged remediation in priority order is possible.

Start with the three that cost nothing and achieve the most – eliminating shared IDs in favour of individual accounts, writing down a rule for immediate suspension of leaver accounts, and reducing the number of people holding system administrator rights. Next, begin periodic export of the permission list, manually if necessary. Then, for the gaps the product cannot close, such as data scope restriction or before-and-after logging, work out how much can be covered by database triggers or peripheral tooling. Whatever genuinely cannot be covered becomes a requirement for the next replacement.

The essential move is not to stop at “the current system cannot do it” but to identify precisely what it cannot do and record that in writing. Audits do not reward perfection. They reward understanding the risk and setting priorities against it.

Frequently asked questions

Who should decide the access design for a production management system?

Not the IT department alone. Role and scope definitions should be decided by the business side, meaning production control, purchasing, quality and accounting, with the IT department translating those definitions into something technically implementable. The appropriateness of segregation of duties should be confirmed by internal audit or the administration function. In practice, the realistic start is a small working group of business-side key people producing a draft role list over about two weeks.

How long should operation logs be retained?

Since no fixed period is prescribed, work backwards. The floor is a length that covers your own audit cycle. If you receive an internal audit once a year, the entire most recent audit period must still be present. Then check the parent company’s document retention policy, the retention practice for tax and accounting records, and any period demanded by customer contracts, and align to the longest. Where storage volume is a constraint, rather than keeping everything for a long time, retain the high-importance records, permission changes, master changes and bulk exports, for longer while keeping ordinary screen access history short.

Where should approval workflow systemisation start?

Start with irreversible operations. Shipment confirmation, stock write-off, period close, master price changes – anything that cannot be undone once executed. Placing approval on those alone captures most of the control benefit. Starting instead with reversible, high-volume operations such as daily work-result entry produces backlogs and the routine never takes hold. Keep the initial scope to somewhere between 3 and 5 operations, run it for six months, confirm it has settled, and then widen it.

Is segregation of duties necessary at a small plant where people hold multiple jobs?

Yes, but not in the same shape as at a large company. Headcount constraints inevitably leave combinations that cannot be separated, and what an audit asks is not whether separation exists but whether the risk was recognised and addressed. List the combinations you cannot separate and attach a compensating control to each. Typical compensating controls are logging every instance of the operation and having a manager or the Japanese management review the list monthly, or setting a value or quantity threshold so that anything above it routes to a different approver. With that list and evidence that it is being executed, holding multiple duties will rarely become a finding in itself.

Summary

Access control in a production management system gets deferred because it never blocks production, and then surfaces all at once as an audit finding or an incident. The points worth carrying away are these.

• The core risk is not the external attacker but the misuse of legitimately granted permissions. In the case Recruit disclosed on 30 March 2026, a former employee used work access permissions to take internal data covering roughly 20,699 people outside the company. Activity performed with genuine credentials can only be distinguished by permission design and by operation logs
• Design permissions in three layers – role, scope and action. Tying them to job titles always breaks. In the action layer specifically, separating view from export is what directly addresses exfiltration
• Document segregation of duties, including the compensating controls where separation is impossible. Creating and approving must not sit with one person, and where headcount prevents that, record the exception together with its compensating control
• Do not copy the paper approval route. Narrow approvals down to irreversible operations. Without delegation and escalation in the specification from day one, the shop floor arrives at password sharing, the worst possible workaround
• Operation logs need all five attributes, in a configuration administrators cannot erase. Who, when, what, what action, from where. Whether before and after values are retained needs checking case by case
• Pair the quarterly permission inventory with immediate suspension driven by HR events. In Thailand, the PDPC has published 5 cases carrying 8 fines totalling roughly 21.5 million baht, so unreviewed security measures are already a live finding rather than a theoretical one

None of this requires major investment to begin. Start by exporting your current permission list. If you cannot export it, that is your first finding.

If you are reworking your permission design, or organising the checkpoints for a production management system selection, you are welcome to talk to TOMAS TECH. We are based in Bangkok and provide the PEGASUS production management system and other shop-floor DX solutions to Japanese manufacturers in Thailand, and we can help with the practical work – drafting the role list, designing approval routes, deciding the scope of operation logging. Getting in touch while you are still framing the problem is entirely fine.

References

• Nikkei report on the Nichirei ransomware disclosure, 14 August 2026
• Monthly security incident roundup for August 2026, TMI Consulting
• Recruit press release on unauthorised removal of information by a former employee, 30 March 2026
• Access management practice under IT general controls, IT Audit Compass, 24 April 2026
• More Than a Warning – Eight Serious Fines Imposed in Thai Data Protection Cases, Tilleke and Gibbins, 1 August 2025