Your data stays separate, and you decide who sees it
No other company using IWB can reach your data: the separation is enforced in the application and again in the database. You set who sees which records and fields with roles and rules, and the log shows you who changed what.
Every customer has its own workspace. IWB separates your records by workspace whenever it reads or saves them, and the database enforces the same separation on its own. This protection is checked every time the application starts, and if the check fails, the application doesn't start.
Files you upload are also kept separate by workspace
Every release re-verifies the separation with automated tests
1When readingIWB returns only the records in your workspace.
2When savingEvery new record is tied to your workspace. Any attempt to write to another workspace is rejected.
3In the database tooThe database enforces the same separation independently. A request that isn't tied to a workspace sees no records at all.
02
Show each person only what they need
You can let sales reps see only their own customers and keep prices hidden from the warehouse team. A role sets the access level in each module, and you can narrow it by record owner (all, own, team, or subunits), branch, and company, or make it conditional with record rules. Each field gets an access level: Hidden, Masked, Read-only, or Edits. When permissions conflict, deny wins; when several roles' field rules combine, the broadest access applies, but a field restriction set for one specific person always comes first.
A hidden field is kept out of screens, lists, exports, printouts, and IWB AI answers; statutory outputs such as the general journal, general ledger, and official reports are exempt
Segregation of duties comes with 15 ready-made rules; for example, someone who issues invoices can't also collect payments
IWB explains, step by step, who can see a record and why
Who can see whatSIP-2026-00188
ANSales repSales team · Ankara branchViews
1PermissionSales order Passed
2ScopeOwn records Passed
3Record ruleBranch: Ankara Passed
4Field security2 fields restricted Passed
Sales priceEdits
DiscountViews
Purchase costHidden
Profit marginHidden
IZSales repSales team · Izmir branch Scope: blocked here
03
Who changed what, and when
When an invoice changes, its history shows who changed it and when. On records such as contacts, orders, invoices, and journal entries, every change is logged field by field with its old and new value. Security events go to a separate log: role, permission, and sharing changes; denied access; sessions opened as another user; and access to sensitive personal data.
You can filter the log down to risky events
When someone works as another user, the log also records the real person behind the session
If a field that's hidden from you changes, you see that it changed, but not the old or new value
/ayarlar/guvenlik-gunluguexample data
Security log
Risky eventsEvent typeDate
Time
Event
Who
Target
10/19, 2:02 PM
Grant changed
System administrator
Sales rep · Role
10/19, 11:47 AM
Access denied
Sales rep
SIP-2026-00188 · Sales order
10/19, 10:15 AM
Sensitive data accessed
HR specialist
Employee record
10/18, 4:20 PM
Impersonation started
System administrator
Sales rep · User
10/18, 9:03 AM
Segregation of duties violation
Accounting specialist
FTR-2026-00241 · Receipt
Field-level change history, with old and new values, also appears on each record's Timeline tab.
04
Keep accounts in the right hands
Password, lockout, and session rules are set per installation. Tightening them doesn't lock out existing users.
Password rules
By default, a password needs at least 8 characters, including uppercase and lowercase letters and a number. Each installation can set a stricter rule.
Two-step verification
Users turn it on from their profile with an authenticator app and get 10 one-time recovery codes. On your own server, you can make it mandatory for all staff accounts.
Lockout and attempt limits
After 5 failed password attempts, the account locks for 5 minutes. Sign-in and password reset attempts from the same IP address are also limited. A failed sign-in doesn't reveal whether the account exists.
Device limit
The number of devices a user can be signed in on at once is limited. If the session on the other device was used in the last 30 minutes, taking it over requires confirmation.
Session management
Users see their open sessions and can end any of them. Changing a password ends every session.
Viewing as another user
Viewing IWB as another user for support requires a separate permission and lasts 15 minutes. Events from that session are logged under the name of the real person who acted.
05
Have your KVKK records ready when asked
IWB comes with privacy notice records, anonymization, data destruction, and access trails for KVKK, Turkey's personal data protection law. What your privacy notices say is up to you and your legal counsel.
Privacy notice records
On each CRM lead, you record when the privacy notice was given, which version of the notice was used, and where consent came from.
Anonymization
You can anonymize users, contacts who are individuals, and contact persons. Identity fields are permanently deleted, while financial documents under statutory retention stay.
Employee data destruction
Employee records past their retention period are listed. HR enters a reason and destroys the personal data: the record stays, but identifying details are wiped.
Sensitive data trail
The log records who opened sensitive personal data and who downloaded files containing personal data.
Masked session records
Session records mask the IP address and store no browser fingerprint. Records of ended sessions are deleted after 90 days.
Closing a workspace
A closed workspace can be restored during the waiting period. After that, it's permanently deleted along with its files.
What data IWB AI sends to its AI provider, what it doesn't send, and how transfers outside Turkey are handled are set out in the IWB AI section of our Privacy Policy. The rules we follow when we process the data in your workspace on your behalf are in the Data Processing Agreement.
06
Passwords, keys, and files
Connection passwords and integration keys are not stored in plain text. Uploaded files are checked by extension and by content.
Passwords you enter for email, your e-invoicing integrator, SMS, and bank connections are stored encrypted.
Integration keys
The key your other systems use to connect to IWB is shown only once, and its plain value isn't stored. A key can't go beyond the permissions of the account it belongs to.
Upload checks
Uploads identified as program files, by extension or by content, are rejected.
Encrypted connection
The connection between your browser and IWB is encrypted. In the cloud, the security certificate is issued and renewed automatically.
Here's a short summary of what your technical team will ask about. We share system requirements and installation documents with your IT team during the quote process.
Data separation is also enforced at the database level and checked at every startup; a release that fails the check doesn't start.
A query without workspace context returns no records, and the application connects to the database through an account that can't bypass this rule.
Every release runs automated separation tests against a real database.
Uploaded files are stored separately per workspace, and path traversal attempts are blocked.
The browser enforces a strict Content Security Policy (CSP), and only a hash of each integration key is stored.
08
Frequently asked questions
Do you support two-factor authentication and single sign-on (SSO)?
Two-factor authentication is available. Users turn it on from their profile with an authenticator app and receive 10 single-use recovery codes. On your own server, you can make it mandatory for all staff accounts. Single sign-on (SSO) is not available. A password policy, account lockout after failed sign-ins, and an attempt limit protect sign-in. IWB also has a per-user device limit and session management. The Google and Microsoft connections are only for linking your mailbox to IWB.
Can your team see our data?
In the cloud, our team uses an admin panel for support and operations. Every change made from the panel is recorded in your company's Security Log as a "Platform operation"; reads from the panel are not logged. On your own server, no inbound connection is opened for administration.
Where does IWB AI send our data?
To generate an answer, IWB AI sends your question and the relevant records to its AI provider, OpenAI. The assistant works only with data you can see; fields hidden from your role are left out of the answer. The IWB AI section of our Privacy Policy explains what is and isn't sent and how data is transferred abroad.
Which third-party services do you use?
IWB AI uses OpenAI as its AI provider. Account emails such as invitations, password resets, and verification codes go out through Resend. Both services are based outside Turkey. A monitoring service runs the public status page, and no personal data goes to it. On your own server, these services stay off unless you turn them on. The full list, and how transfers abroad are handled, are in our Privacy Policy.
Can audit records be deleted?
IWB has no screen for editing or deleting the Security Log or the change log. A record's change history is deleted only along with the record itself. That happens when personal data is anonymized under KVKK, Turkey's personal data protection law, and when a file or task is permanently deleted. If a workspace is permanently deleted, these records are deleted with it.
Where is our data stored?
On your own server, both the database and the files stay on your server. For the cloud, we share the hosting details in writing at the contract stage.