Roles, Permissions & Security (2FA, audit log): Who sees what, who changes what

Who is it for, and what problem does it solve?

This module is for every business where more than one person accesses HR data; it becomes decisive when sensitive data such as salaries, employee documents and health reports must be seen only by the people concerned. When permissions are not defined in an orderly way, two extremes appear: either everyone sees everything, or no one can do their job. A leaver's account stays open, shared passwords circulate, and the answer to “Who changed this record?” cannot be found.

• Company owner and system administrator: manage users, roles and security settings.
• HR and payroll team: access the data their work requires; views of sensitive data are recorded.
• Team manager: sees only the work-related information of their own team.
• Employee: sees only their own record, documents and requests.

What does the roles, permissions and security module do?

The module makes the principle of “least privilege” workable: each user accesses only the records their work requires, and sensitive access and changes leave a trace.

• Built-in roles: company owner, system administrator, HR, team manager and employee. Each role's default permissions are fixed and shown in a read-only table on the settings screen.
• Custom roles: company-specific roles such as payroll specialist, certified public accountant or read-only HR are defined by selecting from the permission list; up to 50 roles per company. A user assigned a custom role has only that role's permissions, so permissions can be narrowed as well as extended. Interdependent permissions, such as edit and read, are selected together.
• Protection against privilege escalation: no one other than the company owner can put a permission they do not have into a role or give it to someone else; no one can assign a role to themselves or edit a role assigned to them.
• Data scope: the whole company, their own team (direct and indirect, from the manager link in the org chart) or only their own record.
• Sensitive data separation: pay and payroll, and special category documents such as health reports and criminal record certificates, open with separate permissions. Identity numbers are not shown in lists or to users without permission; displaying another person's identity number in full is logged.
• Own-record rule: no one other than the company owner can enter leave entries, PDKS records, documents or pay on their own employee card; a person's own requests and clock-ins are excluded from this.
• Two-factor authentication: time-based one-time codes (TOTP) generated by an authenticator app, and recovery codes; each user does the setup themselves. The company owner can make authentication mandatory for all users in the company; there is no per-role or per-user choice, and only the company owner changes the setting. The company owner and the system administrator can reset a user's setup according to the role hierarchy; the reset user's sessions are closed.
• Password security: passwords are stored hashed with the argon2id algorithm and never kept as plain text.
• Account life cycle: the employee is invited to Sora İK from the employee card during onboarding; on leaving, the account is closed by hand during the exit record or at any time. Automatic closing at the end of the leaving date is coming soon.
• Audit log: record creation, changes and deletion (with the names of the changed fields), views of identity numbers, pay history and payroll details, document downloads, exports and custom role changes; built-in role changes do not appear on this screen. On screen, it can be filtered by date, user, action and record type and downloaded as CSV; it cannot be edited or deleted through the interface.
• Login log: successful and failed login attempts are recorded separately; the company owner and system administrator see the company's last 90 days.

Listing and closing open sessions, an access report answering “Who can see this employee's pay?”, data scope by department or location, field-level permission settings and storing previous and new values in the audit log are not available yet; they are coming soon.

How does it work?

The permission structure is set up in five steps at initial setup and then updated along with employee changes.

1. Review the roles. The first account created at company registration has the company owner role; plan operations (pricing) are carried out with this role. Review the built-in roles' default permissions in the table on the settings screen.
2. Invite users. Invite each person with their role from their employee card. Invitations are sent by the company owner and the system administrator; once the company has its first pay record or payroll, payroll read permission is also needed, and if the card has special category documents, permission to view them too (the system administrator has neither; in that case the company owner sends the invitation). Only the company owner grants the system administrator role. Only the company owner grants the HR role as well.
3. Define custom roles if needed. Where the built-in roles do not fit, create a custom role by selecting permissions and assign it to users.
4. Make two-factor authentication mandatory. The company owner switches the setting on for all users in the company; even if you do not make it mandatory, users who access sensitive data should set it up on their own accounts.
5. Review the records regularly. Go through the audit log at regular intervals; close unused roles and accounts.

Why does role-based access matter under KVKK?

Türkiye's Personal Data Protection Law No. 6698 (KVKK) requires the data controller to take appropriate technical and administrative measures to prevent unlawful access to personal data; limiting who can access employee data and monitoring access are core parts of these measures. Role-based access and the audit log help you apply these measures and show that you apply them; whether the measures are sufficient is for your company, as the data controller, to decide.

You can find the guidelines on data security published by the Personal Data Protection Authority on the Authority guidelines page. Retention and destruction, explicit consent records and employees' data subject requests will fall within the upcoming KVKK Compliance Management module. Infrastructure information such as encryption, backups, server location and sub-processors is on the security page; upcoming platform modules such as the notification center and open API are on the Platform & Integrations category page.