Protecting Personal Data in Corporate Systems of Kazakhstan

Where the problem starts: where personal data lives in a company

Personal data rarely lives in a single place. It appears where it’s convenient for people to work: in personnel files, accounting systems, email, messengers and shared folders. As long as “everything seems to work,” this feels normal. The problem begins when no one remembers which copy is current and who has access to it.

Most often corporate systems contain full names, national ID numbers (IIN), phone numbers, addresses, document details, salary and sick leave information, and payment details. Many companies also have client data: contracts, applications, support history and call recordings.

Risk usually comes not from “hackers” but from employee habits. Someone exports a list to Excel “for an hour,” sends it to personal email, forwards it to a colleague in chat or saves it on their desktop. Later the file ends up in a shared folder “for convenience,” and access remains granted forever.

Copies and exports tend to spread to the same places: shared network drives and departmental folders, email attachments, local PCs and USB drives, personal cloud accounts, test databases and “temporary” reports.

No single person is responsible for order. IT usually manages systems and access, Information Security (InfoSec) sets rules and controls, HR manages personnel data, and legal handles requirements and consents. This only works when there is a clear process owner: someone who decides what data can be collected, where it’s stored, who gets access and how quickly it’s revoked.

Data map: what exactly to protect and where it is stored

Start with a data map: a short list of what you have, where it’s stored and who is responsible. Without such a map you can secure the “official” HR fields while forgetting about resume copies, candidate correspondence and files in shared folders.

Personal data in daily work is not limited to IINs and passports. It includes full name, phone, address, personal email, photo, call recording, access pass data, IP address and sometimes combinations like “name + position + salary.”

To avoid applying the strictest rules to everything, split data by sensitivity. For example:

• Basic: client and employee contact details, phone lists, contractual contacts.
• Personnel: questionnaires, resumes, orders, sick leaves, timesheets, performance and disciplinary records.
• Financial: salaries, bank details, tax documents, bills and payments linked to a person.
• Medical: certificates, medical exams, voluntary medical insurance data (if present).

Then go through systems where these data usually live: email and attachments, 1C/ERP, CRM, service desk, file servers and network folders, cloud drives, backups, test databases and exports for reporting.

Assign a data owner at each point on the map. This should be a business owner (e.g., HR for personnel files, CFO for payroll, head of sales for CRM), not IT. The owner decides who needs access and why, while IT configures rights and helps enforce rules.

Data and role separation: a simple model that works

If everyone in a company can “see everything,” instructions won’t help. To protect personal data in corporate systems in Kazakhstan, a simple rule often suffices: grant access only to those who need it for daily work, and only to the specific data they need.

It’s more practical to define roles than to grant rights per person. A role is tied to position, department and typical tasks. Then when an employee is transferred or goes on leave, rights change with the role instead of being adjusted manually.

Roles to start with

Usually 4–6 roles are enough to bring order without complex matrices:

• HR: access to questionnaire data and documents but no payroll data.
• Accounting/payroll: access to accruals and payments without access to unnecessary document scans.
• Line manager: view their team’s data without exporting the entire database.
• Security/Compliance: access on request with recorded justification.
• IT administrator: system management without the right to read personal data contents.

To prevent IT from becoming a “superuser,” separate technical rights (settings, accounts, backups) from business access (viewing records, reports). For sensitive actions use separate admin accounts and a “two pairs of eyes” rule when granting elevated rights.

A related point is environment separation. Test environments must be isolated from production and must not contain real names, IINs or contacts. For integration checks use anonymized datasets and limited exports.

Example: in a branch office HR sees only their branch’s employees, accounting sees only payroll, and an administrator can restart services and restore access but cannot open an employee’s record. This layout reduces leakage risk even if one account is compromised.

How to configure access: clear rules and a working process

Accesss tend to spread not from malice but from everyday situations: someone is transferred, a project ends, and access isn’t removed. So it’s important not only to set rights once, but to establish a simple process that works day-to-day.

The first rule: access is not granted “via a chat request” but through a clear approval route. Typically the data owner (the department head responsible for the system or process) confirms that access is necessary. IT or InfoSec checks the request against the role and the data level, then applies the configuration.

Minimum records to keep: who requested, who was granted access, to what, for how long and who approved.

To make the process robust, tie it to HR events:

• hire: grant basic role-based rights only to systems needed in the first weeks;
• transfer: remove old rights the same day and grant new rights according to the new role;
• termination: block the account immediately and disable access to mail, clouds and messengers using a checklist.

Two-factor authentication is required where risk is higher: remote access, email, VPN, admin panels, financial systems and databases with personal data. For low-risk internal systems a strong password and network restrictions can be sufficient to avoid overburdening users.

Another important practice is separate accounts. An administrator should have a regular account for email and documents and a separate admin account for administrative tasks. This reduces the chance of accidental dangerous actions, phishing compromise, and giving an attacker maximum privileges.

If you are building personal data protection in corporate systems in Kazakhstan, start simple: roles, approvals, expiry dates and regular rights reviews (at least quarterly). This produces more effect than rare, large audits once a year.

Logging: what to log so it helps rather than creating noise

Logging is often turned on “for the sake of it,” and then logs are either empty or full of noise. The point is different: if an incident happens, logs should clearly show who accessed data, what they did and how far it went. Logging is one of the most practical tools: it helps establish facts rather than debating perceptions.

Log not everything, but actions that meaningfully change risk:

• logins and failed login attempts (including admin accounts);
• views of personal data records;
• exports and bulk operations (export, print, report generation);
• role and permission changes;
• deletion or edits of critical fields (IIN, contacts, payment details).

Each entry should answer four questions: who, when, from where and what was done. A minimal set of fields: account and role, exact time, system and module, source (computer, IP, branch or network segment), object acted on (which record or set), result (success/failure) and a short reason if provided (e.g., “per customer request”).

Make sure logs cannot be cleaned. Access to logs is normally given only to InfoSec and security administrators, not to the people whose actions are recorded. A good practice is to store logs separately from the main system and enable alerts for attempts to disable logging.

Retention periods follow a practical logic: “long enough for investigations.” Often this is 3–6 months for operational investigations and up to 12 months if you have branches, high turnover or lengthy internal checks. For example, if accounting runs exports quarterly, 3 months may miss a prior similar operation, while a year will show repeat behavior and the author.

Protecting storage and sharing: encryption, files and “grey” channels

Most leaks happen not through “hacks” but through ordinary actions: a client list is exported to a laptop, sent in a messenger, or uploaded to a personal cloud “for a minute.” So it’s important to secure three areas: devices, backups and file sharing.

Full-disk encryption on PCs and laptops is needed wherever exports and reports with personal data may appear: accounting, HR, call centers and traveling managers. If a device is lost or stolen, encryption makes the data useless without the key.

Backups follow similar logic: an unencrypted backup often becomes a “second database” with the most complete data. Encrypt backups and store keys separate from copies. Assign key custodians and enforce a rule: one administrator should not simultaneously have access to backups and keys without additional approval.

“Grey” sharing channels

A quick win is a simple rule: work data must not go to personal clouds, personal email or personal messengers. But bans alone don’t work — people need a “right way” to share that is no harder than their old habit.

Minimum steps you can implement within a few weeks:

• Add file labels: “PD” (personal data), “internal”, “public”.
• For “PD” forbid external forwarding without approval and encryption.
• Set up auto-rules: warn when sending “PD” by email, block uploads to unknown clouds.
• Keep “PD” in one place with clear rights, not on desktops.
• Regularly delete temporary exports and poorly named files like “Report_final_really.xlsx”.

If you have branches and a shared network, agree on a common approach: data moves only through corporate services, and contractors receive limited extracts rather than “view access to the whole database.”

Backups: how to store and test them to ensure recovery

Even with good access controls and encryption, failures and incidents happen. Backups are your insurance: it’s not enough to create backups — you must be able to restore fast.

A clear rule is 3-2-1, which reduces the risk that both primary data and copies are lost at once:

• 3 copies of data: the working copy plus at least two backups.
• 2 different media: for example, on-site storage and a separate repository/disk.
• 1 copy offsite: a separate location or isolated storage not accessible from the main network.

Also separate backups by purpose. Working backups are for quick rollbacks (deleted folder, damaged document). Archives are for retention requirements and point-in-time investigations. Keep ransomware recovery copies immutable or isolated so an attacker can’t delete them along with servers.

A backup that’s not tested is nearly the same as no backup. Simple approach: once a month perform a test restore not “in place” but into a separate folder or test machine and record the outcome.

• Restore 1–2 typical systems/folders (e.g., personnel documents and a request database).
• Check integrity: files open, the database runs, timestamps match.
• Measure recovery time and compare it to what the business finds acceptable.
• Document steps and any failures.

Finally: access to backups should be stricter than to working data. Use separate accounts, ban shared passwords, and restrict access to those who actually perform restores. Log all backup actions (creation, deletion, config changes, restore) and review logs periodically to spot suspicious operations early.

A 30-day rollout plan (no big projects required)

If you need to protect personal data in corporate systems in Kazakhstan, start with a one-month plan. It doesn’t require a large budget but quickly reduces leakage risk by bringing order to access, logs and copies.

30-day plan

• Days 1–3: make an inventory of systems where personal data appears (1C/ERP, CRM, HR, mail, file storage, messengers). Assign a data owner for each system (the person responsible for rules and access approvals).
• Week 1: define 5–7 typical roles and their needs. Don’t grant access “by name.” Grant by job: accounting, HR, manager, call center operator, IT admin, security.
• Week 2: enable logging in key systems. Agree who triages events: a daily quick check for “red flags” and a weekly review of disputed cases.
• Week 3: configure backups following 3-2-1 (multiple copies, different media, one copy isolated). Perform a test restore on a chosen system — otherwise backups may be useless.
• Week 4: run a short staff training. Focus on clear rules: where to export lists, how to send files, how to label data and what to do if a leak is suspected.

To prevent regression after a month, enforce the process: access only by request and role, and data owners confirm rights quarterly. In companies with branches, agree early on unified account and service access policies.

If you work with an integrator or IT vendor (for servers and infrastructure), ask them to help with procedures and restore tests, not just default configurations.

Common mistakes and traps that cause leaks

The worst leaks usually aren’t caused by hackers. They come from small things: access was given “temporarily” and forgotten, so data remains in shared folders and backups for years.

One main trap is granting access “just in case.” An employee gets rights to personnel folders, CRM or client exports to help out, but the rights aren’t revoked. Six months later they’ve moved roles, but the access stays. Without regular reviews the system accumulates excessive permissions.

A second frequent mistake is a shared account for a department, shift or branch. It’s convenient but makes it impossible to know who viewed or copied data. Shared passwords are often known by many and leave with people when they leave.

Logging is often enabled “for reports” but nobody knows which events matter and who should act. Important traces drown in noise and alerts go uninvestigated.

Backups are another risk. When backups sit next to production data or all admins share the same access, a leak becomes an “everything leaks” event. Backups often contain more data than production and are kept longer.

Finally, test databases are a recurring issue. A developer or contractor needs a quick check and a real production database is copied into test. The test server then runs with looser rules and broader access.

Practices that prevent most of these incidents:

• grant access by role and time limit, with mandatory revocation on role changes;
• ban shared accounts and assign personal accountability;
• set meaningful alerting on logs (mass exports, logins off-hours, access to sensitive sections);
• separate backup access and store copies apart from production;
• anonymize data for tests or use synthetic datasets.

If critical data is kept on in-house servers, embed these rules not only in IT but in HR and operations as well. Then leaks stop being “accidents” and become a managed risk.

Quick checklist: what to check right now

To quickly assess how close you are to basic protection of personal data in corporate systems in Kazakhstan, check a few things that most often lead to leaks because of habits, not hacks.

• There is a clear list of systems containing personal data (HR, accounting, CRM, mail, file shares, messengers) and a named owner for each who is responsible for order.
• Access is granted by roles (e.g., HR, accountant, department manager) rather than ad hoc: roles are described simply — what can be viewed, changed, exported.
• Termination and transfers trigger automatic access revocation: accounts are blocked, tokens and VPNs disabled, and shared-folder rights removed.
• Logging is enabled for key actions: logins, permission grants, exports, bulk changes, deletions. Logs are protected from modification and available to a limited set of people.
• Backups are encrypted, stored separately from production and regularly tested by restoration (not just “a copy exists,” but “we restored and it works”).

A quick real-world test: imagine a branch employee requests access to the client database “for a week.” Can you grant access by role with an expiry date and then verify in logs that they didn’t perform a mass export?

If two or more checklist items are currently “no,” start with system and role inventory. This creates the basis for technical controls and ongoing support (for example, infrastructure deployed and maintained by integrators like GSE.kz).

A realistic example: an average company with branches and a shared network

Imagine a company with 400 employees, a head office and 6 branches. They have an HR system with personnel files, a CRM with client contacts and a shared file server where people habitually dump everything: ID scans, contracts, medical certificates and payroll lists. This is how personal data protection usually begins in corporate systems in Kazakhstan: data is everywhere and access is granted “just in case.”

The first step is to assign data by meaning and owners. HR is responsible for personal files and applications, accounting for payroll and IINs, sales for CRM, and IT for infrastructure but not data viewing. It’s important that IT can manage systems without rights to open sensitive folders.

A practical access model might look like:

• HR: full access to personnel folders, no access to financial registers.
• Accounting: access to payroll registers, read-only access to necessary HR references.
• Sales: access to CRM and commercial documents, no access to personnel or payroll.
• IT: admin rights on servers and backups but no access to “HR” and “Payroll” folders.
• Managers: access by request and time-limited, with mandatory logging.

Logs should help detect suspicious exports. First, check who downloaded large volumes, who copied massive amounts to network folders, who exported from CRM, and whether there were logins out of hours or from unusual branches. It helps to agree on thresholds in advance (e.g., 500 files per hour or a full customer database export) and raise alerts automatically.

Backups are simple but disciplined: daily incremental copies for quick rollback, weekly full backups to guard against silent errors, and isolated copies to survive ransomware.

• Daily: incremental backups of key systems (HR, CRM, file server).
• Weekly: full backup with a restore check.
• Separately: one copy off-domain with separate access.
• Regularly: test that a file or database can be restored within 30 minutes.

Finally, employee rules remove most risks: don’t store personal data in “everyone” folders, don’t send scans to personal messengers, use corporate folders and clear naming templates, and grant access only for tasks and timeframes.

For this scheme a centralized server and clear policies are often enough. Build infrastructure so rights, logs and backups are manageable from one place — for example on racks and servers like S200.

Next steps: lock in order and simplify support

When basic rules are in place (who sees data, what is logged, where copies are stored), make them routine, not a one-off project. Then security won’t fall apart after staff changes or system updates.

Start with a minimal internal rule set. It shouldn’t be voluminous, but must be clear and enforceable:

• data classification and access levels (what is allowed and what is forbidden);
• roles and responsibilities: data owner, administrator, InfoSec, department head;
• access issuance and revocation procedures (including hire, transfer and termination);
• logging requirements and retention periods;
• backup rules and restore verification.

Then pick 2–3 systems with the most personal data and bring them into compliance before moving on. Usually these are HR, accounting, CRM and shared file storage. The criterion is simple: where most personal data accumulates and where access is most often granted manually.

To avoid turning support into manual work, plan workstation and server updates to meet InfoSec requirements: centralized policies, up-to-date OS, disk control and unified configuration templates. For example, if accounting stores reports on a network resource, ensure both workstations and servers enforce the same encryption, update and backup rules.

If internal resources are limited, a systems integrator can handle the most time-consuming parts without an endless project: audit current rights, set up a role-based access model, organize logging and backups with a test restore.

In Kazakhstan the hardware origin and local support often matter. Domestic workstations and PCs (L200, M200) and servers (S200) from GSE.kz can help, along with 24/7 infrastructure support to keep rules effective after network or team changes.