Document security starts with access.

The three groups organise review; they are not mandatory legal categories or completed controls. Verify actual configuration, authority and operational evidence for each item.

Identify whose information a document contains, who needs which operation and what may be shared externally. Granting a software permission does not by itself establish professional or legal suitability.

Compare office responsibilities with actual role and record scope. The authoring team, client or document category is not an automatic private access group. Avoiding unnecessary uploads and reviewing the shared version are separate office steps.

Technical mechanisms and administrative review

Identity, contact, financial or health information may require different review. Assess purpose, access needs, disclosure, retention and disposal for the matter. This guide derives no automatic product setting or sufficient protection from a legal provision.

Technical measures

Verify upload checks, required scanning, operation grants and record/branch scope separately. They do not establish detection of all malware or logging of every access.

Administrative measures

Retention/disposal decisions, responsibilities, training, sharing and incident handling are separate office procedures; the board does not execute them.

For the broader controller duties, see the KVKK compliance guide for law firms. This page covers the document side only.

New file content is checked for filename/extension, size, format header and scanning. Authority, case/branch scope and plan quota are separate prerequisites; a clean scan alone does not mean the record will be created.

The document security flow checks the 25 MiB cap and allowed extensions. Recognised format headers are compared against the extension; this is not exhaustive parsing or detection of all malware. New content is written to storage only after a clean real scan; failure or uncertainty is not acceptance.

A document’s path: upload and separate signing preparation

This fictional overview is not a completed scan or API operation. A record is not considered created before clean-content acceptance. The last signing step is in preparation and unavailable.

Documents

ucret-sozlesmesi.pdfPDF · 0.9 MiBSelected

• Type and extensionWaiting
• Size limit (25 MiB)Waiting
• Malware scanWaiting

Storage

Clean result and acceptance assumed in example

Access

Actual grants and record/branch scope

E-signatureNot yet available

1. 01/05
   UploadAn authorised user selects an example PDF; selection does not mean upload acceptance or creation of a Pending list row.
2. 02/05
   Type and size checkThe example assumes an allowed extension, matching recognised header and size below 25 MiB; exhaustive format parsing is not shown.
3. 03/05
   Virus scanThe example assumes a clean scan. Actual new content is not stored without a clean result; uncertainty/failure is not acceptance.
4. 04/05
   Authorised storageCreation completes under actual authority/scope and quota checks. Preview and download use document.read; a category or authoring team creates no automatic private ACL.
5. 05/05
   E-signature in preparationThe Vekilaw e-signature connection is not yet available. Document dispatch or completed signing is not promised before the provider contract and acceptance are validated.

‹›

01/05

Upload

Fictional check overview, not actual scan/upload/access acceptance. E-signature is unavailable.

Upload gate simulation

Five independent fictional outcomes summarise check categories; they are not one batch upload, a real scan or the exact order of all server validations. Other conditions such as authority and quota are omitted.

1. 01/05

   expert-report.pdf

   PDF · 3.2 MiB

   1. Type and extension

      Passed

   2. Size limit (25 MiB)

      Passed

   3. Malware scan

      Passed

   4. Reason

      Accepted

   The example assumes matching header/extension, valid size and clean scan. Actual creation also depends on authority, scope, quota and commit outcome.

2. 02/05

   setup-tool.exe

   Executable · 1.4 MiB

   1. Type and extension

      Rejected

   2. Size limit (25 MiB)

      Not run

   3. Malware scan

      Not run

   4. Reason

      Rejected

   This extension is not allowed; the example does not proceed to scanning.

3. 03/05

   scanned-archive.pdf

   PDF · 31 MiB

   1. Type and extension

      Passed

   2. Size limit (25 MiB)

      Rejected

   3. Malware scan

      Not run

   4. Reason

      Rejected

   The 31 MiB example exceeds the 25 MiB cap; new content is not accepted.

4. 04/05

   contract-annex.docx

   Word document · 0.8 MiB

   1. Type and extension

      Passed

   2. Size limit (25 MiB)

      Passed

   3. Malware scan

      Rejected

   4. Reason

      Rejected

   In the example scanning is not clean, so new content is not accepted into storage.

5. 05/05

   power-of-attorney-copy.pdf

   PDF · 2.1 MiB

   1. Type and extension

      Passed

   2. Size limit (25 MiB)

      Passed

   3. Malware scan

      Did not finish

   4. Reason

      Rejected

   With no completed result, new content is not accepted. Check service status and failure cause; assume no automatic resubmission.

Filename validation does not mean every dangerous character is sanitised. Scanner failure does not establish safety. The real scanner connection and upload acceptance require separate operational verification.

Tip: do not open a rejected file on your own machine. If a flagged document arrived by the client's email, confirm with the sender through a separate channel; their account may have been compromised.

Document names are illustrative review topics; rows are not product categories, automatic ACLs, signing clearance or retention schedules. The office determines access needs, signing/form review and retention grounds per document.

Sensitivity labels are illustrative, not mandatory product classes or legal clearance. E-signature providers, document categories and retention decisions are independent.

Review effective role/direct grants through roles and permissions. Preview, download and version reads use document.read; upload needs document.create, updates/version append document.update, deletion document.delete and deleted-record restoration document.restore. Sharing additionally needs document.share and document.read. The access guide distinguishes scopes.

Least privilege and per-company isolation

Private record reads are constrained by tenant/branch and linked-case access checks. Role names or categories do not create private groups automatically. Anonymous sharing is separate: a holder of the link and optional password can open content; this is not verified client identity.

Activity logs

Technical audit covers supported writes; version and share records retain their own metadata. They are not one screen showing every private preview/download, actual recipient identity or complete access history. Assess evidence gaps separately during review.

MFA

Distinguish account MFA enrollment from company requirement policy. An authorised actor enabling policy must first enroll their own account; other members are not enrolled automatically. Own sessions span the account. The security page separately explains operational conditions.

Separate permissions

Preview/download share document.read; write and sharing grants are separate.

Company isolation

Private tenant/branch/record scope and anonymous sharing are different paths.

Activity record

Supported write audit is not a person-by-person history of all access.

MFA

Account enrollment, company policy and sessions are assessed separately.

Do not equate electronic approval, signature type, certificate and representation authority. Separately review permitted methods, form requirements and channel rules using current official sources. This guide approves no document for signing.

1. 01Verify signatory identity and representation authority separately.
2. 02Determine the required signature type and certificate conditions.
3. 03Review the final version and integrity.
4. 04Assess form and channel requirements for the transaction.

Law No. 5070 and other rules governing the transaction are review sources. An on-screen approval or file signature metadata alone does not prove validity, an appropriate certificate or compliance with form requirements.

UYAP and Vekilaw provider connections have separate scopes. A version record does not establish UYAP submission or provider-completed signing. Actual methods, provider protocols and acceptance are not yet completed.

Which document gets which signature

1. 01/03

   Secure electronic signature

   Qualified review verifies required signature type, certificate and transaction conditions; this guide gives no automatic clearance.

2. 02/03

   Simple electronic approval

   Do not equate click/email approval with the effects of different signature types; assess the method for the transaction.

3. 03/03

   Wet ink or notarial form

   Separately verify required form and permitted channels against current rules for the transaction.

The signature record in Vekilaw

The Vekilaw e-signature connection is in preparation. Signature dispatch is not offered before the technical contract and actual acceptance of company-selected providers are complete. The integrations page distinguishes available and planned connection scope.

Document management supports appending file versions; not every metadata edit creates a content version. Restoring accessible clean earlier content creates a new incremented version subject to quota/current-version checks. History is not an infinite archive independent of deletion/retention; no sentence-level diff or legal evidentiary approval is promised.

Creating a share link is not email/SMS delivery. The link pins the selected current VersionId at creation; subsequent uploads do not move it to the new version automatically. Expiry is 1–30 days; a password is optional. Possession of the link/password is not verified client identity.

Safe sharing rules

Right channel

Send documents only to an email address or phone number the client has confirmed to you; avoid group chats.

Minimum content

Review the shared version for necessary data; creating a link does not redact content automatically.

Record the transfer

Track delivery and recipient verification separately; a link record is not proof of delivery or identity.

Review links at closure

Expiry/revocation constrain future eligible opens; they do not recall downloaded copies or guarantee termination of every started stream.

Assess link forwarding

The link and optional password can be forwarded; the product does not guarantee access only by a verified client.

Determine purpose, grounds and retention/disposal decisions separately per document. Active documents are not automatically age-deleted by category. Office policy and the product’s physical cleanup window for deleted records are different.

A deleted document can be restored only with permission, an unexpired restoration window and no started purge; accidental deletion is not always reversible. Physical cleanup and privacy request tools are separate workflows; actual storage/DB acceptance is verified separately.

Backup

Verify backup existence, encryption/access, retention cycles and actual recovery through operational evidence. The guide or source tests do not establish production backups or a completed recovery exercise.

Offboarding a departing employee

The office sets its departure plan for its work and data requirements. These are separate review topics, not an automatic sequence, universal deadline or one operation closing every system.

1. 01Distinguish team removal from company membership removal; review account sessions and remaining memberships.
2. 02Review case/task responsibilities under existing grants; assume no automatic bulk handover.
3. 03Assess available records; assume no person-level history for every download.
4. 04Review share links, API keys and external accounts under their own revocation rules.
5. 05Apply office retention, communication and confidentiality procedures separately.

For a suspected incident, assess scope and required steps with authorised responsible people. This list is neither automated incident handling nor legal approval of notification duties/deadlines. Do not assume records cover every access.

1. 01/05

   Stop it

   Use authorised operations to assess relevant membership/session and share access; account for external systems managed separately.

2. 02/05

   Scope it

   Review available technical records, versions, shares and other evidence; record coverage gaps separately.

3. 03/05

   Notify

   Determine applicable recipients, form and deadlines using current official sources and qualified legal review.

4. 04/05

   Record it

   Write down the incident, your decisions and their timing.

5. 05/05

   Fix the cause

   Find why it happened, strengthen the relevant checklist item and brief your staff.

Official notification forms and deadlines can change; confirm the current Board announcements and decisions on the KVKK Authority website.