IT General Controls for Thai Subsidiaries – Practical ITGC Guide 2026

When a Japanese parent company is listed, its Thai subsidiary falls within the scope of Japan’s internal control reporting system too. Complying does not stop at tightening a few system access settings. This article breaks down what IT controls actually need to cover, area by area within IT General Controls (ITGC), and walks through a workable process plus a realistic estimate of the workload for a Thai subsidiary team.

The internal control reporting system was revised, and that changes what IT controls need to cover

IT staff and Japanese expatriate managers at Thai subsidiaries increasingly say the same thing – “head office requests suddenly got much more detailed this year.” The reason is a revision to the reporting system itself. Understanding that background matters, because without it, requests from head office look like one person’s arbitrary demands, and local teams will not cooperate.

When the revision was announced and when it took effect

Japan’s Business Accounting Council published the revised standards and implementation guidance for internal control reporting on April 7, 2023. They apply to fiscal years starting on or after April 1, 2024, so for a company with a March fiscal year-end, the fiscal year ending March 2025 was the first one covered. Because the first year of application depends on each company’s fiscal year-end, check first whether your company is already under the revised rules or is about to be.

For most Japanese-affiliated companies, that means 2026 falls in the second or third year of operating under the revised rules. That is also why so many people report the same pattern – auditors held back in year one and then started raising specific findings from year two onward.

The stated purpose shifted from “reliability of financial reporting” to “reliability of reporting”

One of the framing changes in the revision is that the stated purpose of the basic internal control framework shifted from “reliability of financial reporting” to the broader “reliability of reporting.” That points toward covering disclosure information beyond the financial statements, and it also made the evaluation of fraud risk explicit.

There is an important limit here, though. Japan’s Financial Instruments and Exchange Act (FIEA) itself was not amended, so the internal control that an internal control report actually covers is still, as before, “internal control over financial reporting.” The scope of evaluation and reporting has not suddenly expanded to cover non-financial information across the board.

Even so, the change matters in practice for local operations – mainly because of fraud risk. Fraud risk at overseas sites now has to be treated as something evaluators must consider, and as a result, local teams are asked more often to explain the control status of the operational systems that feed the financial numbers. The old assumption that reviewing the accounting system alone is enough never really held, and it holds even less now.

Mechanical application of numeric thresholds was rejected

This is the change with the biggest practical impact. Under the old approach, deciding the scope of evaluation effectively relied on numeric thresholds – “roughly two-thirds of consolidated revenue,” or “the three accounts of sales, receivables, and inventory.” The revision makes clear that these thresholds should not be applied mechanically, and shifts the approach toward a risk-based judgment that weighs qualitative significance instead.

Note that this is not simply “the scope gets narrower.” Even a site with small revenue can fall into scope for qualitative reasons – elevated fraud risk, unusual operations, or a history of deficiencies. A Thai subsidiary that contributes only a few percent of group revenue being pulled into scope for the first time is exactly the kind of outcome this shift produces.

The same thinking now applies to IT. For IT application controls, rotational evaluation on a fixed schedule such as “once every three years” is no longer supposed to be decided mechanically by year count; in an environment with frequent cloud migrations or system replacements, annual evaluation may be needed, and the appropriate frequency should be discussed with the auditor. The old assumption that “we evaluated it last year, so we can skip it this year” no longer holds automatically.

The report now has to say more

The required content of the internal control report expanded too. Companies now have to add supplementary notes covering the rationale for how the scope was determined, the metrics used and the basis for the percentages applied, and, where a material weakness existed in the prior year, the status of its remediation.

For local staff, that means one more task. It used to be enough to report the conclusion – “in scope” or “out of scope.” Now head office also needs enough supporting material to explain in writing why that scope was chosen. If the local team cannot produce the numbers and the rationale, the head office internal control team has nothing to write from.

Which companies this covers, and the penalty for getting it wrong

The system applies to roughly 3,900 listed Japanese companies and their consolidated subsidiaries. If a Thai subsidiary is inside the parent’s consolidation scope, it is not outside this system. And a false statement in an internal control report carries a personal penalty of up to five years’ imprisonment, a fine of up to JPY 5 million, or both.

Raising this point with local staff tends to change the mood in the room. It helps to frame ITGC work not as “the auditor being fussy about small things” but as part of a system where filing a report containing false statements can carry criminal liability for the individual who signs off on it. That framing makes it much easier to build local cooperation.

IT General Controls (ITGC) domains – access management, change management, operations management, and outsourcing

IT General Controls, usually shortened to ITGC, sit at the core of IT control work. This section breaks down, area by area, what a Thai subsidiary is actually asked to demonstrate on the ground.

How ITGC relates to IT application controls

Start with the overall structure. IT controls are generally described in three layers – entity-level IT controls, IT General Controls (ITGC), and IT application controls. IT application controls ensure that individual business transactions are processed correctly – input validation and the accuracy of an automated calculation are typical examples.

ITGC is the foundation underneath those application controls. If ITGC is weak, the application controls running on top of it cannot be trusted either. No matter how precisely a calculation is built, its result means nothing if anyone can rewrite the production program that runs it. That is why auditors put so much weight on ITGC.

A terminology note – ITGC domains are not the same thing as the “three-document set”

One point causes confusion on the ground, so it is worth clearing up first. In internal control terminology, the “three-document set” (san-ten setto) usually refers to three specific documents – a process narrative, a flowchart, and a risk control matrix (RCM). Separately, when people talk about the components of ITGC, they mean the division into domains such as access management, change management, and operations management. Some explanations add outsourcing management as a fourth domain.

These two things are not the same, and mixing them up causes real trouble – a request for the “three-document set” from head office gets answered with access management materials, and the conversation goes nowhere. When a request comes in, confirm first whether it means the documents or the domains.

Access management

Among the ITGC domains, access management is where auditors tend to concentrate their findings. What is required is that the record of who can access which system, with what level of authority, is actually managed, and that the current state can be shown by evidence to match what was intended.

In concrete terms, the following controls are typically in scope.

• User ID registration, modification, and deletion go through a request and approval process.
• Access rights are limited to the minimum needed for the job.
• Privileged IDs are restricted, and their use is logged.
• ID inventories are performed periodically, confirming that IDs belonging to people who have left or transferred no longer remain active.

Privileged IDs deserve extra attention here – they are accounts with broad authority to change configuration or data, and they get scrutinized closely alongside the ID inventory itself. The scope of review is not limited to business applications either. Administrator rights on cloud services, access to network equipment, and even physical access records for entry to the server room are all part of what gets checked, and that physical-access piece is the one local teams most often overlook.

For the design-level question of how to split roles and structure approval flows within a single system, our article on role design and approval flows for production management system access rights covers that in detail. This article sits one level above that – it is about how you tie multiple systems together as part of the overall reporting compliance effort.

Change management

Change management is the domain that ensures changes to a system go through a proper procedure. It is sometimes called development and maintenance management.

The elements to cover are change requests and approvals, testing performed and recorded, and separation between the development and production environments. Of these three, environment separation is where Thai subsidiaries most often stumble. It is not unusual for a small site to run everything on a single server, with a local vendor patching production directly.

Arguing “we are too small, please make an exception” rarely gets accepted. Once a site is in scope, its small size is not by itself a reason to skip a control – the responsibility instead shifts to explaining what is being done in its place. If true separation is not feasible, a more realistic path is to design a compensating control, such as requiring prior approval for any production-environment work plus a record of the work actually done afterward, and to be ready to explain why that substitute is adequate.

Operations management

Operations management is the domain that keeps a system running reliably. Its main elements are backups, job monitoring, and incident response procedures.

The question here is not “are backups being taken” but “is someone confirming they succeeded.” A state where the backup job had been failing silently for three months with nobody noticing gets judged as a control that is not working. What gets evaluated includes whether there is a retained record confirming each backup succeeded, and whether recovery has actually been tested.

We cover the mindset needed to make backups actually recoverable, not just copies sitting on a drive, in our article on business system backup strategy. The points worth checking overlap heavily whether you are thinking about audit readiness or business continuity.

The fourth domain – managing outsourced vendors

When ITGC is organized into four domains, outsourcing contract management is added alongside access, change, and operations management. Its elements are the criteria for selecting vendors, clearly defined SLAs, and periodic evaluation of vendors.

This fourth domain is exactly where a Thai subsidiary tends to feel the most impact. Local sites typically run with one or two IT staff, and server maintenance, networking, and application modifications are almost always outsourced to a local vendor. If the vendor is the one actually touching the system, the control explanation has to extend to how that vendor’s work is managed too.

Summarizing the ITGC domains gives the following picture.

Notice how often the word “evidence” keeps coming up. Treat the practical work of building ITGC as being just as much about leaving a record that a control actually worked as it is about designing the control in the first place.

Five reasons ITGC is hard to build at a Thai subsidiary

Handing a procedure manual written by the head office internal control team straight to a local site often does not work as intended, because constraints exist locally that simply do not apply to a site inside Japan.

Surface the local constraints first

Practical guidance on evaluating internal controls at overseas subsidiaries points out that time-zone and language differences slow communication down, and that translation work needs to be built into the schedule ahead of time. It also notes that inadequate physical control of inventory at overseas sites tends to make embezzlement and similar fraud more likely there than in Japan.

Mapped onto issues specific to Thai subsidiaries, the picture looks like this.

Of this table, the headcount row is the one people underestimate the most. Tell a site with a single IT person to “separate the requester from the approver” and it sounds physically impossible to them. But what a control actually requires is separation of duties, not separation of people – handing the approval role to a business department or to management makes it work. Whether a team can make that mental shift changes how heavy the burden feels locally.

In concrete terms, this means assigning distinct roles for who submits a request, who approves its content, and who keeps the record. Cases where a control looks impossible for lack of headcount often turn out, on closer look, to be cases where nobody separated the roles in the first place.

How far you can rely on the parent company’s evaluation

There is one more point that has a real effect on cost and workload. Where an overseas subsidiary uses a system belonging to the parent company, the subsidiary is generally allowed to rely on the parent’s evaluation of that system. If a Thai site connects to and uses the head office accounting system, there is no need to re-evaluate that system’s ITGC from scratch locally.

The flip side is that a production management system introduced independently at the local site, or a local accounting package, has to be evaluated locally – there is no way around it. Before starting the build-out, sort the systems in scope into “shared with head office” and “local only.” That sorting step alone is usually enough to give a realistic sense of how much work the local team is actually facing.

How to build out ITGC – five steps

Building out ITGC starts with defining the scope of evaluation, moves through designing and documenting controls, then evaluating the design and evaluating the operation, and finishes with remediating whatever deficiencies turn up. Projects that skip this order and jump straight to writing procedure manuals tend to fail, because the workload balloons while the actual scope is still undefined.

What happens at each step

Breaking the work down stage by stage gives the following.

The difference between step 3 and step 4 is worth keeping straight. A design evaluation checks whether a rule exists and has been put into a form that applies to actual work; an operating effectiveness evaluation checks, by sampling evidence, whether that rule was actually followed over a period of time. A perfectly written procedure manual still counts as a deficiency in the operating effectiveness evaluation if not a single record shows the procedure was followed.

A realistic order to actually start in

With limited headcount, the order you start in matters. The approach we recommend is building the evidence templates first. Distribute record formats – an ID request form, a change request form, a backup confirmation sheet – and get people using them, and only then finish writing up the formal wording of the rules. Following that order means that by the time the rules are formally approved, months of evidence have already accumulated.

Do the opposite – starting from the wording of the rules – and evidence sits at zero for however long it takes the rules to get approved, which often leaves nothing to sample when the first-year operating effectiveness evaluation comes around. Because the deadline for compliance is the fiscal year-end and cannot move, securing time for evidence to accumulate should come first.

How to cover the internal audit function

Plenty of local sites have no internal audit function at all, or the person nominally covering it is stretched too thin to actually do it. On this point, guidance from a firm offering internal audit outsourcing and co-sourcing describes an arrangement where, as companies expand overseas and the risk at overseas sites keeps rising, audits covering overseas subsidiaries are handled jointly with local specialists. It is worth knowing that co-sourcing exists as an option – sharing just part of the work with an outside specialist rather than handing over everything.

Rather than treating this as an all-or-nothing choice between keeping everything in-house or outsourcing everything, it is more workable to treat it as a line-drawing question – how much to keep internal, and where handoff to an outside party begins. The same thinking applies broadly to the IT department’s functions in general, and the framework we cover in our article on IT department outsourcing in Thailand for drawing that line applies directly to dividing responsibility for controls as well.

Estimating the cost and workload of building ITGC

This is the section everyone most wants to read, and also the one that needs the most care. We separate clearly what can be stated as fact from what is an estimate built on stated assumptions.

Published market rates – but watch what scope they cover

A published guide to IT governance build-out costs gives the following levels by phase.

Read these figures carefully – the scope is not ITGC on its own, but IT governance build-out as a whole. The same guide explains the relationship this way – IT General Controls under J-SOX (Japan’s SOX-equivalent internal control framework) are one part of IT governance, and building out governance brings the ITGC foundation along with it. Applying the figures above directly as an ITGC-only estimate overstates the cost.

Four factors are given for why cost varies – the number of processes in scope, the number of sites, the tier of the firm engaged, and the depth of the deliverables. On firm tier specifically, the guide notes that major audit-firm-affiliated consultancies typically start above JPY 5 million, mid-tier consulting firms start from JPY 2 million to 3 million, and independent firms or those that stay on through implementation show an even wider range. The same guide presents a modeled estimate – about JPY 13 million and roughly 12 months – for a company with 300 employees, a 10-person IT department, and a scope narrowed to 15 COBIT processes, but it explicitly labels that figure a hypothetical model rather than an actual project’s numbers.

As for the cost of commissioning ITGC build-out support locally in Thailand, we could not find reliable published statistics. Local labor cost levels differ from Japan’s, so the domestic Japanese figures above cannot simply be transplanted. If you need an actual number, the most reliable path is to lay out the number of systems in scope and whether documentation already exists, then get quotes from several firms.

A modeled in-house workload case – a hypothetical estimate built on stated assumptions

Since a reliable market rate cannot be given, here is a way to estimate the effort in person-days instead. What follows is not published statistics but a hypothetical estimate built on the assumptions stated below. Actual workload will vary considerably depending on whether documentation already exists and how cooperative the vendor is.

The assumptions are as follows.

• One Thai subsidiary, with 100 to 300 employees.
• About three systems that are local-only fall in scope; systems shared with head office can rely on the parent’s evaluation.
• Two local IT staff and one Japanese manager are available to work on this.
• Head office has Japanese-language rule templates, but the local versions have to be built from scratch.

Under these assumptions, the workload guideline for the first year and for subsequent years looks like this.

Adding those up puts the first year at roughly 60 to 100 person-days and the years after that at roughly 30 to 50 person-days. For a site with two IT staff, the first year works out to somewhere between one-tenth and one-fifth of their annual capacity going toward this compliance effort – a meaningful load to add on top of day-to-day operations and incident response.

What matters from this estimate is not the absolute numbers themselves. The important point is that the nature of the workload changes between the first year and later years. The first year is dominated by one-time work – writing documents. What remains from year two onward is ongoing work – ID inventories and accumulating records. Get through year one without deciding who owns that ongoing piece, and evidence gaps will show up the following year, sending the whole effort back to square one.

On return on investment, it is healthier not to expect too much. Building ITGC is not an initiative aimed at recovering an investment – it is work needed to satisfy a baseline requirement of being part of a listed company group. It does produce useful side effects, such as cleaner access rights and a better backup setup, but building the budget justification around those side effects as the main goal leads to the wrong scope decisions.

Points that come up most often in auditor reviews

Even a site that has finished the whole build-out can still get flagged during an audit. Knowing the patterns that come up most often lets you close them off in advance.

The typical findings

The findings that come up again and again on the ground look like this.

• An ID belonging to someone who has left the company is still active. This typically happens because HR’s resignation process and IT’s ID deletion process are not linked.
• Privileged IDs are shared accounts, so who actually performed an action cannot be identified.
• Change approval exists only as an email exchange, making it hard to pin down who approved what and when.
• Backups are being taken, but there is no record confirming they succeeded.
• Local vendor work proceeds on verbal agreement, with no work report ever produced.
• Written rules exist, but actual operation differs from them, and nobody can explain which one is correct.

That last one is especially awkward. Write the rules too ideally, and real operation cannot keep up with them, which turns into a deficiency in the form of a rule violation. Keep this principle in mind – a modest rule that is actually followed is a stronger control than an impressive rule nobody can keep.

Building a state you can actually explain

What an auditor’s evaluation mostly comes down to is two questions – has a necessary rule been defined for what is being managed, and does actual operation follow that rule. The means of confirming both of those boil down to whether records and evidence exist, and whether approval was obtained from someone with the authority to give it.

So what needs to be prepared is not a perfect control, but a state you can explain. Having a deficiency is not itself fatal. What matters is whether, once a deficiency is found, its cause has been analyzed, a remediation plan exists, and progress against that plan is on record. The revision’s new requirement to report the remediation status of a prior year’s material weakness is an extension of exactly this thinking.

Align terminology between the local team and head office

A surprisingly common source of confusion is simply vocabulary. Head office speaks in Japanese internal control terminology, while local staff understand things through general English or Thai IT terms. Words like “control,” “deficiency,” “design evaluation,” and “operating evaluation” do not carry across a literal translation.

A single one-page glossary built before the evaluation starts is a genuinely effective fix. Line up roughly twenty terms used in this compliance effort in three columns – Japanese, English, and Thai – and rework caused by miscommunication drops noticeably from that point on. This is another concrete case of the earlier point that translation work should be built into the schedule in advance.

Frequently asked questions

How much does building out ITGC cost?

Published domestic Japanese benchmarks for IT governance build-out put assessment at JPY 2 million to 5 million, build and implementation at JPY 5 million to 15 million, and adoption support at JPY 1 million to 3 million. These figures are not limited to ITGC, though – they cover the whole of IT governance build-out, of which ITGC is only a part. Applying them directly to an ITGC-only project overstates the cost.

We were also unable to confirm reliable published figures for support costs specific to Thailand. When requesting quotes, settle three things first – the number of systems in scope, whether rules and procedures already exist, and how much localization work is needed – and you will get back numbers you can actually compare across firms.

How far can a Thai subsidiary rely on the parent company’s IT control evaluation?

For the portion running on a parent-company system, the subsidiary is generally allowed to rely on the parent’s evaluation. If the local setup simply connects to and uses the head office accounting system, there is no need to duplicate an evaluation of that system’s ITGC locally.

On the other hand, a business system introduced independently locally, or a server and network maintained by a local vendor, does need to be evaluated locally. Sorting systems in scope into “shared with head office” and “local only” at the very start of the build-out is the single most effective step for cutting out wasted work.

Does IT General Controls evaluation need to happen every year?

As long as a system is in scope, IT General Controls are evaluated every fiscal period. The evaluation that has had some room to reduce frequency is IT application controls’ rotational evaluation, which assumes ITGC is already effective. Do not confuse the two.

Even for that rotational evaluation, the revision made explicit that frequency should not be set mechanically by year count, such as “once every three years.” In an environment with frequent cloud migrations or system replacements, annual evaluation may be needed, and the appropriate frequency is something to discuss with the auditor. Avoid deciding on your own that “we evaluated it last year, so this year is unnecessary” – especially in a year when the system configuration changed, it is safer to align your thinking on evaluation frequency with the auditor ahead of time.

Conclusion

Here are the points worth keeping in mind about IT controls for internal control reporting, from a Thai subsidiary’s operational perspective.

• The revision was published on April 7, 2023, and applies from fiscal years starting on or after April 1, 2024. For a company with a March fiscal year-end, the fiscal year ending March 2025 was the first one covered.
• The stated purpose of the basic internal control framework shifted from “reliability of financial reporting” to “reliability of reporting,” and the evaluation of fraud risk was made explicit. The internal control that an internal control report actually covers, however, is still internal control over financial reporting, as before.
• Mechanical application of numeric thresholds for scope was rejected in favor of a risk-based judgment weighing qualitative significance. A site contributing only a small share of revenue can still fall into scope.
• Rotational evaluation of IT application controls should likewise not be decided mechanically by year count, and frequency now needs to be discussed with the auditor.
• Think of ITGC as four domains – access management, change management, and operations management, plus outsourcing management. That fourth domain matters especially at a Thai site with heavy vendor dependence.
• The build-out proceeds in this order – scope decision, control design and documentation, design evaluation, operating effectiveness evaluation, and remediation. Distributing evidence templates early and starting operation before the rules are formally finalized makes the first year noticeably easier.
• Published cost benchmarks cover IT governance build-out as a whole, and overstate the cost when applied to ITGC alone. No reliable published benchmark exists for Thailand-specific costs, so confirm them through quotes from several firms.

The compliance deadline cannot move, while local headcount does not grow overnight. That is exactly why deciding early where the line falls between what stays in-house and what gets shared with an outside partner pays off. TOMAS TECH is based in Bangkok, building and operating production management and energy management systems for Japanese-affiliated manufacturers, and we also get involved in building out local IT structures and reviewing access management and backup operations. We are happy to talk even at an early exploratory stage – how much of your systems is likely to fall in scope, or how to make the evaluation workable for a small local team – so please reach out through our contact form.

References

• Key Points of the Internal Control Reporting System Revision – Issoh (Japanese)
• Review of the Internal Control Reporting System and How Companies Should Respond – Nikkei Cross Tech (Japanese)
• Explanation of the Revised Internal Control Standards – EY Japan (Japanese)
• What Is the Internal Control Reporting System (J-SOX) – Overview of the Revised Standards and Related Practice – THE FINANCE (Japanese)
• Internal Audit Outsourcing and Co-Sourcing – PwC Japan (Japanese)
• The Internal Control Reporting System Revision and Its Application Timing – IPO Support Media (Japanese)
• Cost Benchmarks for Building IT Governance – GXO (Japanese)
• The Four Domains of IT General Controls (ITGC) and Evaluation Practice – TOKIUM (Japanese)
• J-SOX Compliance – Basics of Internal Control Evaluation at Overseas Subsidiaries – AIM Consulting (Japanese)