Ensure Contractors are Identified as Users
Ensure contractors are labeled distinctively from other personnel in systems.
Plain language
In your organisation's system, it's important to clearly label contractors separately from permanent staff. This matters because if contractors aren't easily identified, there might be confusion over what they can access, and they might unintentionally gain access to sensitive information they shouldn't see.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
July 2020
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for personnel securityTopic
User IdentificationOfficial control statement
Personnel who are contractors are identified as such.
Why it matters
If contractors aren’t identified as such, access reviews and offboarding can miss them, increasing risk of lingering access, data exposure and audit noncompliance.
Operational notes
Tag contractor accounts in the identity system (e.g., user type/attribute) and verify this label during joiner/mover/leaver reviews and periodic access recertification.
Implementation tips
- HR should identify all current contractors in the organisation's records. This means going through employment records and marking who is a contractor. Be sure to update this list regularly.
- The IT team needs to clearly label contractor accounts within all systems. This can be done by adding 'CON' to their username or using a separate user group for contractors. This helps in easily separating them from permanent staff.
- Managers should inform contractors of their specific access levels. Set up a short meeting to explain what systems they can access and why certain restrictions are essential. Record what is discussed and agreed upon.
- The IT department should regularly review access logs to ensure contractors are only accessing appropriate systems. Use a simple checklist to compare contractor actions against their permitted access.
- Procurement teams, when hiring new contractors, should inform the IT team immediately. Provide the necessary details like duration of their contract and systems they need access to so the IT team can set up proper accounts.
Audit / evidence tips
-
Askthe list of current contractors from HR: Request the document or database that indicates all current contractors
Goodincludes a comprehensive, up-to-date list with clear markings of contractor status
-
Askto see the account naming convention policy from IT: Request the documentation outlining how contractor accounts are set up
Goodwould show explicit guidelines that separate contractors from regular staff
-
Asksystem access logs from the IT team: Request recent system access logs showing higher-level access attempts by user accounts
Goodconfirms that all access aligns with authorised permissions tied to contractor roles
-
Askto see access permissions: Request details of the permissions given to contractor accounts in the system. Check for restricted permissions in comparison to permanent employees
Goodhighlights that contractors have access only to the systems they need, with limited access rights
-
Askmanagers for documentation of communicated access limitations: Request notes or emails showing what access information was communicated to contractors
Goodis documentation that reflects clear communication tailored to individual contractor roles
Cross-framework mappings
How ISM-1583 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 5.16 | ISM-1583 requires organisations to ensure personnel who are contractors are clearly identified as contractors within systems | |
| handshake Supports (2) expand_less | ||
| Annex A 5.18 | ISM-1583 requires organisations to ensure contractor accounts are identifiable as contractor users within systems | |
| Annex A 8.2 | ISM-1583 requires organisations to label contractor personnel distinctly from other users in systems | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.