Document-based access control

What document-based access control means

In document-based access control, a physical or digital credential does not grant access on its own. Instead, it works as an identification key that lets the system check a consolidated status. Does the company have authorisation? Does the worker belong to the right company? Are the role, training, fitness, induction and other applicable requirements valid? Does the requested access match the authorised location, time and activity?

When the answer comes from approved rules and up-to-date data, access control is no longer just a physical barrier. Instead, it becomes the operational execution of a document policy. As a result, the turnstile, barrier, door or checkpoint applies a decision that the system prepared before the person arrived on site.

This approach is especially relevant in operations with contractors, multiple employers, high-risk activities, shared equipment and high staff turnover. In Portugal, Article 16 of Law No. 102/2009 (the legal framework for occupational safety and health) governs cooperation between employers when several companies carry out activities at the same location. However, competent professionals must validate the specific configuration of requirements, and the platform cannot infer it on its own.

 

Five layers you should keep separate

Identity

It confirms who or what is in front of the system: the person, company, vehicle or equipment.

Credential

The means of identification: a card, QR code, RFID tag, mobile app or other identifier.

Document evidence

Any document or record that someone submits to demonstrate a requirement.

Compliance

The result of validating the evidence against approved, applicable criteria.

Access authorisation

A contextual decision to allow or prevent an entry, zone, time slot or activity.

 

Critical distinction: A person may have correct identification and hold a valid credential, yet still lack authorisation for a specific activity. Likewise, an uploaded document does not equal a compliant requirement.

 

How to design the decision logic in 9 steps

1. Define the scope of each access

Start by identifying what you are authorising: entry to the perimeter, access to a zone, the start of an activity, driving a vehicle, using equipment or staying beyond a certain time. “Authorised access” is too broad when different risks and responsibilities exist.

For example, the same person may have permission to enter an administrative area but not to work at height. The model should therefore allow proportionate decisions, avoiding total blocks when only one activity has restrictions.

 

2. Approve requirements and activation factors

Each requirement needs a source, an owner and a condition of application. For example, some apply to all contractors, while others depend on the company, contract, role, risk, location, equipment, shift or project phase. The rule should also state why it exists and when it stops being necessary.

Document management then translates these decisions into operational criteria. However, it should not create legal, technical or contractual requirements on its own initiative.

 

3. Establish a single source of truth

The access system needs to know where to check the valid status. When spreadsheets, emails, the document platform, the HR system and access control keep different versions, the decision becomes unpredictable. Therefore, define which system is the authority for identity, employment link, requirements, validation, credential and access event.

For this reason, integrations should carry statuses and identifiers in a controlled way, rather than copying personal documents indiscriminately into the physical access system.

 

4. Use statuses with operational meaning

Statuses such as “pending” or “incomplete” are not enough. For example, the team should distinguish between not submitted, under review, needs correction, compliant, expired, waived by rule, approved exception and suspended. In addition, each status needs an owner, a date, a rationale and a known consequence.

The consolidated status should explain whether a critical requirement is missing or only information with no impact on access. Without this distinction, the system may produce too many blocks and lead teams to work around the control.

 

5. Map statuses to access outcomes

Authorised: all applicable critical criteria are compliant and the system permits the requested context.

Authorised with limited scope: the person can enter but cannot carry out a certain activity or access a specific zone.

Manual review: there is ambiguity, a recent update or a dependency that requires a human decision.

Temporary exception: a competent authority has approved limited access, with a deadline and compensating measures.

Blocked: a requirement that the organisation defines as preventing access in that context is missing or invalid.

In addition, the operator and the contractor should be able to understand the outcome without exposing unnecessary personal data. “Access not authorised: critical requirement pending” may be enough at the entry point, while the details remain available only to competent profiles.

 

6. Control synchronisation and latency

A validation completed on the platform should not take hours to reach access control without anyone knowing. Therefore, define the frequency, maximum propagation time, receipt confirmation, failure handling and reconciliation between systems.

Synchronisation should only be bidirectional when there is a clear need. The entry event can return to the platform for traceability, but this does not mean that the physical system can change document criteria.

 

7. Govern exceptions without creating permanent access

Exceptions are sometimes necessary for emergencies, visits, critical interventions or system transitions. They should include the reason, the approver, the person and scope covered, compensating measures, the time slot, the expiry date and the record of the decision. Indeed, an exception with no defined end becomes a parallel authorisation.

For this reason, avoid universal codes, shared cards or informal lists at the gatehouse. Even in a contingency, each access should belong to a named person or tie clearly to a traceable decision.

 

8. Define behaviour in the event of failure

What happens if the document platform, the network or the integration service becomes unavailable? You should not improvise the answer on the spot. Instead, define by zone and risk whether the system keeps the last valid decision, blocks new access, only allows exits or routes to manual validation.

The choice between failing closed and maintaining continuity should come from a risk assessment. In all cases, you must record the failure, any access granted and the subsequent reconciliation.

 

9. Record, test and review the complete decision

A useful log links identity, credential, access point, date and time, the status checked, the rule applied, the outcome, any exception and the operator involved. The access record does not need to expose the full document; however, it should hold enough of a reference to reconstruct the decision.

Test normal and adverse scenarios: an expired document, a recent validation, a duplicate credential, a transferred worker, an unauthorised activity, a network failure, an expired exception and an emergency exit. In this way, the test should prove that the right decision reaches the right device.

 

Which criteria can feed the authorisation

Contractor company

Contractor approval status, active contract or work order, defined insurance or authorisations, no suspension and a relationship with the location.

Worker

Identity, link to the company, role, suitable fitness, applicable training, induction, specific authorisations and credential validity.

Activity and risk

Work at height, confined spaces, electrical work, driving, hot work or other conditions that the competent assessment defines.

Equipment and vehicle

Identifier, ownership, applicable technical documentation, inspection, maintenance, insurance or authorisation for use.

Context

Location, zone, time, shift, project, team, work phase, mandatory supervision or maximum number of people.

The minimum technical chain

  • First, the document platform receives evidence and applies approved validation criteria.
  • The rules engine then consolidates the status by person, company, equipment and context.
  • Next, the integration sends only the identifiers and statuses that the access system needs.
  • The credential identifies the object that someone presents at the turnstile, barrier or mobile app.
  • The controller then applies the decision and records the event.
  • Finally, the team reconciles events and failures for monitoring, auditing and improvement.

 

Mistakes that weaken the model

Blocking simply because an upload is missing

The requirement may not apply to that role, location or activity.

Granting access because a file exists

The document may have expired, be unreadable, belong to the wrong person or still await review.

Using a single global expiry date

The company, worker, training, equipment and authorisation may expire at different times.

Copying documents to the turnstile

The access decision needs status and context, not excessive exposure of data.

Not setting an expiry for exceptions

The temporary authorisation turns into permanent access without grounds.

Ignoring synchronisation failures

The system applies an old decision and nobody knows that the statuses have diverged.

Allowing shared credentials

The link between identity, decision and event disappears, which compromises traceability.

Measuring only blocked entries

Many blocks can point to poorly defined criteria, delayed data or a process that is hard to comply with.

Data protection by design

Access control processes identity data, employment links, time and location data and, potentially, sensitive information related to fitness for work. The GDPR requires defined purposes, minimisation, accuracy, security and data protection by design and by default. For this reason, the access point should only receive the information it needs to decide and to guide the person towards resolving the issue.

Separate profiles: the security guard or operator may need to know the outcome and the referral procedure, but not to consult medical documents, contracts or copies of ID. Likewise, define how long you keep events, who can access the logs, how you respond to data subjects’ rights and the rules for sharing with contractors.

 

Note on biometrics: Using biometrics adds specific requirements. The CNPD (the Portuguese data protection authority) sets out its own conditions for attendance control and access to the employer’s premises, including the use of non-reversible representations. You should therefore validate the specific system before implementation; this article does not recommend biometrics as a default option.

 

Indicators that help improve the process

  • Percentage of correct decisions, confirmed through sampling and reconciliation tests.
  • Time between document approval and the actual update at the access point.
  • Blocks by requirement, cause, contractor, location and criticality.
  • Access granted by exception, by duration, approver and recurrence.
  • Discrepancies between the document platform and the physical system.
  • Orphaned, duplicate or unreturned credentials, or credentials linked to inactive people.
  • Integration failures and access that took place during a contingency.
  • Time to resolution, from the block to valid authorisation.

Interpret the indicators together. For example, a sharp drop in blocks may mean better documentation or a rule that the system no longer applies. On the other hand, a rise may reveal greater rigour, changed requirements, poor communication or a synchronisation failure.

 

Implementation plan for 30, 60 and 90 days

0 to 30 days

Map access points, systems, credentials, objects, requirements and owners. Then choose one site and one pilot workflow with controlled impact.

31 to 60 days

Approve statuses, rules, outcomes, exceptions and behaviour on failure. Next, configure the integration and test scenarios with test data.

61 to 90 days

Run the pilot, measure latency and decisions, train operators and contractors, fix failures and approve the phased expansion.

 

Frequently asked questions

Should the system block anyone with an expired document?

Not automatically. The consequence depends on how applicable and critical the requirement is and on the scope requested. For example, a document linked to a specific activity can restrict that activity without preventing all access.

Does a valid credential prove compliance?

No. The credential identifies the person and may have its own validity; compliance, however, results from assessing the applicable requirements and can change before the card expires.

Do you need to integrate the platform directly with the turnstile?

There is no single architecture: you can use direct integration, middleware or updates through an intermediate service. In any case, the essential point is to control the source, latency, security, confirmation and reconciliation.

How should you handle visitors?

Define a separate workflow, with proportionate identification, a host, zones, times, supervision and safety information. In addition, do not reuse the worker rules without assessing their purpose.

Does automatic access remove human decision-making?

No. It reduces repetitive decisions when the rules are clear, but you still need owners to define criteria, validate evidence, handle exceptions, investigate failures and review outcomes.

Does compliant documentation guarantee that the work is safe?

No. Document compliance is evidence and a preventive control. However, it does not replace supervision, assessment on site, real conditions, safe behaviour or technical skills.

 

How GEDOC connects documentation and operations

GEDOC’s public pages present an approach in which document compliance governs access and operational continuity. GEDOC ID links credentials to document information and provides for integration with barriers, turnstiles and other systems, so that decisions reflect the compliance status. In addition, GEDOC Review supports document review against defined requirements, while GEDOC Service handles the configuration and technical administration of platforms.

The value comes from the combination: criteria the client approves, consistent review, a correctly configured platform, credentials linked to the right identity, controlled integration and continuous monitoring. However, none of these layers, on its own, guarantees a sound decision.

 

Next step: Choose one access point and try to reconstruct a real decision. Which identity did the person present, which criteria applied, which status did the system check, when did it last update, which rule decided and what exception existed? If the answer depends on several spreadsheets or on individual memory, there is a clear opportunity for improvement.

 

Discover GEDOC ID, GEDOC Review and GEDOC Service to assess how to connect document compliance, credentials and operations.

 

Related articles and services

GEDOC ID, credentials linked to document status

Document review against requirements: GEDOC Review

GEDOC Service, configuration and technical administration

RFID for equipment, document status in the field

Access control in the renewable energy sector

Document history management policy

 

Editorial note and sources consulted

This article addresses organisations operating in Portugal. Its content is informative and does not constitute legal advice, an OSH opinion, a recommendation of biometrics or a guarantee of compliance. Competent professionals should validate criteria, access consequences, data processing and integrations.

Sources consulted on 11 August 2026:

Diário da República, Law No. 102/2009, in particular Article 16

EUR-Lex, GDPR, Articles 5, 25 and 32

CNPD, thematic guidance on biometrics

GEDOC, GEDOC ID

Services: GEDOC Review and GEDOC Service (GEDOC)

GEDOC, access control in the renewable energy sector

Further reading: Contractor and subcontractor management: A complete guide.

We don’t just implement platforms. We make sure they work.

Talk to the AISP team about implementation, administration and ongoing support for your operation after go-live, in any country, from administration centres in Portugal.