Access control policy: a practical guide for Australian businesses

MFA, password rules and administrator access generate the most visible operator concern. Offboarding and access reviews appear less often in public discussion, but failures there create some of the clearest real-world exposures.

• business with employees, contractors or outsourced IT — Cover every human and non-human identity, including vendors, shared services, service accounts and emergency accounts.
• APP entity covered by the Privacy Act — Access controls become part of the reasonable technical and organisational measures used to protect personal information under APP 11.
• Essential Eight or ISM-aligned organisation — Map the policy to the target maturity level and applicable ISM controls rather than treating it as a stand-alone document.

Access to the organisation’s systems, applications, accounts, networks, information and data repositories must be based on a verified identity, a documented business need and the minimum permissions required for the person or service to perform authorised duties. Access must be approved before it is granted, reviewed while it remains active, changed when duties change and removed promptly when the business need ends.

• cloud and SaaS-heavy business — Include every externally hosted application, vendor portal, API key, integration account and identity provider, not only the corporate network.
• business handling sensitive or high-value information — Add stronger approval, logging, monitoring and recertification requirements for sensitive data repositories and high-impact systems.

Every user must have a unique identity unless a shared account is technically unavoidable and expressly approved. Each access request must identify the user or service, the system and information involved, the requested role or permissions, the business reason, the approver, the start date and any expiry date. The organisation must retain a record of the access granted, later changes, review decisions, exceptions and withdrawal.

• Essential Eight Maturity Level One — Apply MFA to the online services, third-party services and customer services specified by the maturity model, especially where sensitive data is handled.
• Essential Eight Maturity Level Two or Three — Use MFA for privileged and unprivileged system users and implement the phishing-resistant requirements for the relevant services and repositories.
• small business without enterprise identity tooling — Start with email, remote access, finance, cloud administration, password managers and other high-impact accounts, while planning a move away from weaker factors.

Multi-factor authentication must be enabled for privileged accounts, remote access and all other systems or services designated by the organisation. Phishing-resistant MFA must be used where supported and proportionate to the risk, with weaker methods treated as transitional or fallback controls. User passphrases must be long, unpredictable and unique and must not be shared or reused. Routine 90-day changes are not required unless a system, contract or documented risk requires them; credentials must be changed immediately when compromised, suspected of compromise, exposed in clear text or otherwise affected by a defined security event.

• small business using an MSP or external administrator — Give the provider named, attributable accounts and only the systems and time window needed; do not rely on one permanent shared super-admin login.
• Essential Eight Maturity Level Three — Add just-in-time administration and the stronger segregation and privileged operating-environment controls required by the maturity model.

Users and services must receive only the minimum access required for authorised duties. Privileged users must use a separate named privileged account solely for administrative work and a separate unprivileged account for email, web browsing and routine activity. Privileged access must be approved, protected by MFA, logged, reviewed and removed when no longer required. Permanent local administrator rights and shared administrator accounts are prohibited unless a documented exception is approved.

• small business without a CISO — The owner or chief executive should approve the policy and nominate a senior manager or trusted provider to administer it, while business managers approve individual need.
• larger or regulated organisation — Separate policy ownership, business approval, technical provisioning and assurance, with system and data owners accountable for their access populations.

The Policy Owner is [role]. The board, executive or business owner approves this policy. Access to a system or information set must be approved by the relevant manager, system owner or data owner based on a documented business need. IT, the service desk or an identity administrator may provision approved access but must not approve access solely because they administer the technology. Conflicts of interest and self-approval are prohibited unless an emergency process expressly permits them and records a later independent review.

• remote or SaaS-heavy workforce — Maintain a complete application and identity inventory so offboarding reaches services outside the main directory, including tokens, integrations and vendor portals.
• contractors and temporary staff — Use named accounts, an accountable sponsor and an automatic expiry date rather than relying on someone to remember later.
• Essential Eight Maturity Level Two or Three — Revalidate privileged access at least every 12 months and disable it after 45 days of inactivity, while still removing access sooner when the business need ends.

New access must be based on an approved role or specific request before the user starts. A change of duties must trigger review and removal of access that is no longer required, not only the addition of new access. When employment or engagement ends, access must be removed or suspended on the same day the legitimate requirement ends, or immediately where risk requires it. Temporary, contractor, vendor and emergency access must have an owner and an expiry or formal revalidation date.

• Essential Eight assessment or contractual assurance — Provide evidence against the exact target maturity level and document any approved exceptions and compensating controls.
• business seeking cyber insurance — Preserve evidence for every representation made in the proposal, especially MFA scope, privileged access, offboarding and periodic reviews.

The organisation must retain evidence sufficient to show that access controls operate in practice. Evidence must include current policy approval, access and privileged-account inventories, access requests and approvals, provisioning and removal records, MFA and identity configuration, access-review results, exceptions and expiry dates, relevant event logs, and records showing that identified excess or inactive access was remediated.

• organisation implementing the Essential Eight — Map policy requirements to the chosen maturity level for MFA and administrative privileges and track exceptions through an approved, reviewed process.
• APP entity covered by the Privacy Act — Treat access control as one layer in the reasonable technical and organisational measures protecting personal information throughout its lifecycle.
• organisation not covered by APP 11 or not formally adopting Essential Eight — The ACSC and OAIC guidance still provides a strong Australian risk-management baseline, but label it as guidance rather than a legal or certification claim.

This policy supports the organisation’s implementation of the Essential Eight multi-factor authentication and restriction of administrative privileges strategies and the organisation’s obligations under APP 11 where the Privacy Act applies. The organisation must not represent that it has achieved an Essential Eight maturity level unless all eight strategies have been assessed against the applicable requirements. Access controls for personal information must form part of layered technical and organisational security measures.

• business with outsourced IT or multiple SaaS administrators — Check ownership of tenant-level accounts, reseller portals, recovery methods, API keys and vendor emergency access.
• legacy environment — Document controls that cannot yet meet the target, approve time-limited exceptions and use compensating controls rather than silently claiming compliance.

Shared credentials, anonymous or generic administrator use, unowned service accounts, standing privileged access without a current business need, and access without an identifiable approver are prohibited. All exceptions must record the reason, affected systems and users, compensating controls, accountable owner, approval date and expiry date. Exceptions must be reviewed before expiry and removed when no longer justified.

This guide and its templates are a professionally drafted starting point, not legal advice. Your obligations depend on your industry, your contracts and your data. Have a qualified adviser review anything high stakes before you rely on it.