Summary
AccessOS covers who may enter a site, who did, and what to do when the building has to be emptied. For most providers its real value is the second of those: presence records from access control are independent evidence of attendance, produced by a turnstile rather than by a register somebody filled in.
Who This Guide Is For
- Operations and campus managers
- Facilities and security staff
- Quality officers looking for corroborating attendance evidence
Prerequisites
- Sites captured under provider settings and facilities
- A view on who is allowed where, and when
- Access hardware, if you have it — much of the module works without it
Step 1: Model the Site
Navigate to Access → Sites.
Capture the site, its zones and its doors. A zone is an area with a common access rule — the workshop, the residence, the admin block. Doors belong to zones; policies apply to zones rather than to individual doors, which is what keeps a policy readable.
Step 2: Connect Devices, If You Have Them
Navigate to Access → Devices.
Readers, turnstiles and controllers register here, and their health is monitored. A reader that has stopped reporting is a gap in your evidence for every hour it is down, so the health view matters more than it first appears.
If you have no hardware, skip this. Visitor management, policies and musters all still work.
Step 3: Write the Policies
Navigate to Access → Policies.
A policy says which people, in which role, may enter which zone, on which schedule. Write them in terms of roles rather than named individuals — a policy naming forty people is a policy that is wrong the moment somebody leaves.
Access → People shows the resulting entitlements per person, which is the view to check when somebody says they cannot get in.
Step 4: Manage Visitors
Navigate to Access → Visitors.
Pre-register expected visitors — assessors, moderators, verification panels, employers. A visitor log is often the first thing an external verifier asks to see, and one that was maintained continuously reads very differently from one assembled afterwards.
Step 5: Read Presence as Evidence
Navigate to Access → Events.
Access events become presence sessions: when a person was on site and for how long. This is corroborating evidence for attendance, not a replacement for the register — a person can be on site and not in class. Where the two disagree, the disagreement is the useful information.
Step 6: Prepare for an Evacuation
Navigate to Access → Emergency.
The muster view answers “who is on site right now”. Test it before you need it. An emergency roll call that has never been run once in calm conditions will not work in an evacuation.
Step 7: Biometrics, Carefully
Navigate to Access → Biometrics only if you use biometric access.
Biometric data is a special category under POPIA. The module records processing records and consents separately from the biometric enrolment itself, because you will be asked to produce them. Collect consent explicitly and keep an alternative for people who decline.
What Good Looks Like
- Policies are written against roles, not names
- Device health is watched, and outages are known
- The visitor log is continuous
- A muster has been tested in calm conditions
Common Mistakes
- Using presence as the attendance register. It corroborates; it does not replace.
- Naming individuals in policies. They rot immediately.
- Enrolling biometrics without recorded consent and an alternative. That is a compliance failure, not an administrative one.