Digital personnel file in SharePoint: data protection, permissions, and HR workflows

Can a digital personnel file in SharePoint be operated in compliance with data protection laws and reliably in daily operations? Technically, this is possible if personnel documents are stored in a clearly defined area, access is consistently controlled via roles, and for each document category, purpose, legal basis, retention, blocking, and deletion are established. SharePoint provides document libraries, versioning, search, and permissions; Microsoft Purview can supplement retention, records management, and audit; Power Automate can control deadlines and workflows. However, none of these building blocks replace the labor and data protection law review of the specific personnel process.

Therefore, a digital personnel file in SharePoint should not start as a regular team storage with a folder per employee. First, data categories, roles, and lifecycle are defined. Only then does the technical structure follow.

Legal Notice: The following content describes technical design principles and not legal advice. Permissible documents, legal bases, participation rights, information procedures, and retention periods differ by country, industry, collective bargaining agreement, and contract situation. They must be definitively established by the responsible data protection, HR, and legal functions.

What a digital personnel file must deliver

A personnel file is not just a storage location. It must support the entire controlled lifecycle of personal employee data:

1. Document is taken over from a permissible source.
2. It is uniquely assigned to a person and a document category.
3. Only authorized roles can view or edit it.
4. Changes and business approvals remain traceable.
5. Deadlines, blocks, and deletion events are handled rule-based.
6. Information, correction, and audit processes are executable.
7. Upon exit, content is not deleted en masse or retained indefinitely, but processed by category.

SharePoint fulfills the technical storage, metadata management, role-based sharing, and versioning from this list. Purview can provide retention rules and audit functions. A complete HRM system often additionally includes payroll, time management, recruiting, talent management, job plans, and statutory notifications. These functions do not arise automatically through a SharePoint library.

Data inventory before architecture

Before building, all document types must be inventoried. For each category, at least the following information is necessary:

Property: Purpose

Example question: Why is the document processed?

Property: Legal basis

Example question: On which approved basis does the processing rest?

Property: Responsible role

Example question: Who is authorized to manage the content for the business?

Property: Read permission

Example question: HR, manager, payroll, data protection, employees?

Property: Right to modify

Example question: Who is authorized to set a new version?

Property: Retention

Example question: What deadline applies from which event?

Property: Lock

Example question: When is processing allowed only in a restricted manner?

Property: Deletion

Example question: Who reviews and approves the deletion?

Property: Origin

Example question: HR system, upload, scan, email, workflow?

Property: Special category

Example question: Does the document contain particularly sensitive data?

Typical categories can be contract, addendum, qualification, certificate, assessment, absence proof, or exit document. The specific classification must not be taken over en masse from a technical template.

Making data minimization visible

The GDPR requires that personal data be appropriate to the purpose and limited to the necessary extent. For SharePoint, this means:

• no private notes without a defined purpose,
• no document copies in multiple sites,
• no full-text or metadata fields that are not required for the process,
• no unlimited retention "for all cases",
• no unnecessary sharing with managers or project roles.

A technical mandatory field should always correspond to a business requirement.

Structure: one site, libraries, or one site per employee?

Variant a: central HR site with libraries

A heavily restricted HR site contains one or more document libraries. Each file receives metadata such as employee ID, document category, validity, and retention class.

Advantages:

• central administration,
• uniform content types and views,
• simplified search and reporting for authorized HR roles,
• fewer sites and owners.

Risks:

• individual permissions per person create many unique permission scopes,
• a configuration error can affect many files,
• very large libraries require good indexes, views, and operating rules.

Variant b: folders or document sets per person

A folder or document set bundles a person's documents. This is understandable for navigation but must not become an uncontrolled individual permission landscape.

Advantages: coherent file, clear personal reference.

Risks: broken inheritance for each folder, hard-to-verify exceptions, accidental sharing or moving.

Variant c: site per person

A site per employee creates strong isolation but very high administration effort. Provisioning, owners, retention, search, archiving, and deletion must work for each site. For normal personnel files, this pattern is usually disproportionate; it can only make sense for special organizational or regulatory requirements.

Variant d: separate areas by protection level

In many cases, a combination makes sense:

• general personnel documents in a central, tightly restricted library,
• especially sensitive categories in a separate site or library with a smaller group of authorized users,
• documents for employee self-service in a controlled portal or app,
• leading master data in the HR system instead of in SharePoint.

Thus, the protection level is not represented solely through hundreds of individual folder permissions.

Recommended metadata model

A file should not be identified only by its filename. Suitable metadata are:

Field: Employee ID

Purpose: stable assignment to the person

Field: Document ID

Purpose: unique business identifier

Field: Document Category

Purpose: controls view, rights, and retention

Field: Document Date

Purpose: creation or validity date

Field: Valid from/to

Purpose: deadlines for qualifications or agreements

Field: Status

Purpose: draft, reviewed, valid, superseded, locked

Field: Source

Purpose: HR system, upload, scan, workflow

Field: Responsible HR Role

Purpose: business owner

Field: Confidentiality Class

Purpose: technical protection control

Field: Retention Class

Purpose: reference to approved retention rule

Field: Termination Date

Purpose: only if business-required and from leading source

Use a stable employee ID instead of name or email as the primary reference. Names can change, and email addresses are removed upon departure. Display name and current organization can additionally be stored or shown at runtime from a leading source.

Permission concept: who can see and change what?

Define roles before people

A possible role model is:

• HR file administration: create, classify, and correct documents,
• HR processing: read and edit defined categories,
• Payroll: only categories relevant to billing,
• Executive: only explicitly shared documents of assigned individuals,
• Data protection/Audit: controlled audit access,
• Employees: possibly access to selected own documents,
• technical administration: platform management, but no blanket domain-specific access as a process assumption.

The actual role distribution must be decided organization-specifically.

Group-based and smallest rights

Permissions should be assigned via Entra or SharePoint groups. Direct user rights are harder to verify. Each role receives only the necessary actions: read, add, edit, delete, share, or manage permissions.

Site Owners are particularly critical. Whoever is an Owner can generally change permissions extensively. Owner access must therefore be limited to a few active individuals, regularly reviewed, and protected whenever possible with strong authentication.

Do not derive executive access from free text

If executives are allowed to see certain files, the assignment must come from a reliable source. A free text field Vorgesetzter in a SharePoint list is error-prone without synchronization. Better is a controlled organizational relationship from the HR system or Entra ID, supplemented by a process for matrix organization, deputy roles, and historical changes.

Verify search and preview access

Access tests must not be limited to opening a folder. Check:

• SharePoint search,
• Microsoft 365 search,
• previews,
• recently used files,
• sharing links,
• mobile apps,
• synchronization with OneDrive,
• export or download options.

Security Trimming should prevent unauthorized results but must be validated with real roles and test documents.

Technically support GDPR requirements

Purpose binding and transparency

Document in the record of processing activities which data is processed in SharePoint. User information, internal policies, and operations documentation must match the actual configuration.

Storage limits

Retention is not solved with a single global deadline. Different document categories can have different start points and obligations. A deletion concept therefore needs:

• shared category,
• deadline,
• triggering event,
• possible blocking or legal dispute exception,
• person responsible for disposition,
• evidence of execution.

Purview Retention can store content for a defined period or delete it after expiration. The specific behavior during processing and deletion depends on the policy, label, and record configuration and must be verified in a test environment.

Rights of affected persons

For access, correction, restriction, and deletion, the system must reliably find relevant documents. A stable personal ID, documented data sources, and clear categories are more important than a nice folder tree.

When correcting information, an incorrect piece of information should not be overwritten without control if proof obligations exist. Define whether a new version, a correction document, or a domain-specific block is required.

Security of processing

Appropriate security measures can include strong authentication, Conditional Access, device controls, Sensitivity Labels, encryption, audit, limited downloads, and regular permission reviews. Which measures are required depends on the risk.

HR workflows with Power Automate

Automation is sensible when it is based on a clarified data model. Typical flows are:

• check and classify incoming documents,
• report missing mandatory metadata,
• announce expiration of a qualification,
• track outstanding documents in onboarding,
• Convert the exit event into a document-based lifecycle,
• Prepare for deletion or disposition review,
• Report permission deviations to HR and IT.

Document intake as a controlled process

A secure upload workflow can look like this:

1. The file lands in a restricted intake library.
2. The flow checks the file type, employee ID, and required metadata.
3. HR confirms the category and domain-specific accuracy.
4. The file is moved to the target library.
5. Retention class and status are set.
6. Processing is logged.

A flow should not move personnel documents based solely on a filename. Incorrect spelling or duplicate names can otherwise lead to the wrong file.

Connect onboarding and offboarding

Onboarding workflows can provide expected documents and statuses. The article Employee Onboarding with Power Platform and SharePoint describes such a process pattern. For exit, Onboarding and Offboarding with Power Automate, Entra, and SharePoint is relevant.

Important is the system boundary: The onboarding flow controls tasks; the personnel file preserves only permitted documents. Not every task log belongs permanently in the file.

Typical error patterns and fallback paths

Error: HR site inherits enterprise-wide visitors

Symptom: The site was taken over from a general template or a hub and contains overly broad groups.

Test: Check permissions with a normal employee account and search.

Fallback: Immediately restrict access, inventory external and internal sharing, check the audit, and assess the data breach incident process.

Error: every personnel folder has its own direct permissions

Symptom: Permission reviews are hardly possible; moves break access.

Correction: Consolidate roles and protection classes, especially separating sensitive categories.

Fallback: Gradually return rights to defined groups; perform migration with test accounts.

Error: retention period is only a free-text field

Symptom: Documents are never or inconsistently deleted.

Correction: Connect shared categories with technical retention rules and disposition processes.

Reversion: controlled inventory review; no blanket mass deletion without legal approval.

Error: flow assigns document to the wrong person

Cause: Name or email instead of stable employee ID, ambiguous filenames, or outdated master data.

Reversion: stop automatic processing, lock affected documents, audit and check access, correct assignment by two authorized persons.

Error: synchronization or download creates local copies

Risk: Revoked cloud rights do not remove already downloaded files.

Correction: check download and sync requirements by protection class, include device management and sensitivity labels.

Test plan before production

Permissions

• Test HR admin, HR specialist, payroll, manager, employee, and unauthorized user.
• Check direct links, search, preview, download, and synchronization.
• Examine owner and administrator roles separately.

Document lifecycle

• Walk through intake, classification, change, replacement, lock, and deletion review.
• Test wrong employee ID and missing metadata.
• Simulate exit with multiple document categories.

Retention and audit

• Apply label or policy to test documents.
• Check editing and deletion behavior with multiple roles.
• Search audit events and test export access.
• Simulate legal dispute or lock exception.

Information and correction

• find all documents for a test person using stable IDs,
• correct a false assignment,
• check the export for completeness and unauthorized third-party data,
• document the process.

Restart

• deactivate the flow and use manual intake,
• keep faulty documents in quarantine,
• after restoration, reconcile all incidents,
• do not automatically reprocess any file without a verified classification.

Limitations of SharePoint as an HRM system

SharePoint can support a document-centric personnel file if requirements, roles, and lifecycle are manageable. A specialized HR or document management system is more appropriate when complex statutory reporting, payroll, workforce planning, bulk documents, self-service, cross-border regulations, or certified archiving processes are needed.

The technical decision should be based on a requirements matrix. The article Audit-Proof Documentation in SharePoint covers versioning, audit trails, retention, and electronic signatures in depth.

How to keep the digital personnel file GDPR-compliant and manageable in operations

A viable digital personnel file begins with an approved data inventory and does not end with the upload. Stable employee IDs, a few clear protection areas, group-based roles, document-category-specific retention, and tested HR workflows keep the storage traceable. SharePoint, Purview, and Power Automate can technically support these rules; however, permissible purposes, deadlines, and access roles must be formally decided outside the system and reviewed regularly.