Technically, connecting a reporting tool to an ERP takes a few minutes: a server address, a username, a password. Most of the risk comes from exactly that ease. In many companies, reporting tools connect with the all-powerful admin user created during the ERP installation. In this article we explain, in plain terms, the security questions to ask when connecting a reporting tool or any external software to your ERP, why read-only access is essential, and the personal data side of things.
What does read-only mean, and why is it essential?
Read-only means a user can see records in the database but cannot add, change or delete any of them. Since a reporting tool's only job is to read, it needs nothing more.
The risks of a connection with write access are:
- A badly written query or a software bug can change records
- If the reporting tool itself is compromised, an attacker can write to the ERP
- The audit trail gets blurry: when a record changes, you cannot tell whether it came from an ERP user or the external tool
The principle of least privilege is the core rule here: each user gets the minimum permissions needed to do their job, and nothing more.
A dedicated user with a narrow scope
A separate database user should be created for the reporting tool. This user:
- Should have read-only permissions
- Should, if possible, access only the databases needed for reporting
- Should not be the same as the ERP's own admin user
- Should have a strong password not used anywhere else
- Should be documented: on whose behalf it was created and why
A dedicated user also makes it possible to revoke access in a single step when needed. If you stop using the reporting tool, you simply disable that user; there is no need to change the ERP's own passwords.
The network side: the database should not be exposed to the internet
Exposing the ERP database server directly to the internet is a serious risk we see often in the field. The reporting tool should connect from inside the company network or through an encrypted tunnel (such as a VPN). On the firewall, the database port should be open only to allowed addresses.
Performance is a security issue too
Heavy, poorly written queries can slow down the ERP during the workday, and an afternoon when the accounting team cannot issue invoices is an outage for the business. The reporting tool's queries should be lightweight, large scans should be scheduled outside working hours, and query load should be monitorable when needed.
Who holds the password and connection details?
Creating a secure user is not enough; where that user's credentials live also matters. It is common to find connection details sitting in an email thread, in a text file on an employee's desktop, or on a settings screen of the reporting tool that everyone can see. Connection details should be stored only on the reporting tool's server, out of sight of unauthorized people, and shared over a secure channel when necessary. Rotating the password when staff or vendors change should also be a routine step.
Personal data and KVKK
An ERP holds not only commercial data but also personal data: payroll records, employees' ID and bank details, contact details of individual customers. When connecting a reporting tool, ask these questions:
- Which personal data does the reporting tool access, and is that access necessary?
- Who can see sensitive reports such as payroll?
- Is data transferred to a server outside the company, and if so, where?
- Has the data processing relationship with the service provider been defined in writing?
We describe our general approach to KVKK (Türkiye's Personal Data Protection Law) on our KVKK compliance and our KVKK approach pages.
ERP connection security checklist
| Check | Yes / No |
|---|---|
| A separate database user was created for the reporting tool | |
| This user has read-only permissions only | |
| The ERP admin user is not used in external tools | |
| The database server is not directly exposed to the internet | |
| The connection runs over the company network or an encrypted tunnel | |
| Sensitive reports (payroll) have separate viewing permissions | |
| You know where data is transferred and stored | |
| The procedure for revoking access is written down |
Every row that comes out "no" is an issue to resolve before the connection is set up.
How we do it at Globya
We start reporting projects with this list. READERP was designed around this principle: it connects read-only to the common ERP and finance platforms on the market, led by Netsis and Logo, the ERP systems widely used in Türkiye, and never writes a single row to the ERP. Installation is done the same day, and we work with your IT team to create the separate, read-only user. Ready-made views for Cash, Receivables, Revenue, Stock, Payroll, Cash cycle and Confirmation come out of the box, and you can ask questions in plain Turkish. Regardless of which tool you connect, if you want to review the security of your existing ERP connections, a free preliminary analysis is a good place to start. For method options, also see our article on management reporting from Netsis and Logo data.
Frequently asked questions
Can a read-only connection really never change ERP data?
If read-only permission is defined at the database level, the user cannot add, change or delete records. Because the restriction is enforced in the database rather than in the application, no writes happen even if there is a software bug.
Is it a problem to give the ERP admin password to a reporting tool?
Yes. The admin user has every permission, and once it is shared you cannot trace who did what. Always create a separate, read-only user for the reporting tool.
Should payroll data appear in the reporting tool?
It depends on the need. Payroll reports are valuable for management, but access should be limited to authorized people only, and the justification for access should be defined for KVKK purposes.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.