Compliance documentation is the structured body of manuals, policies, procedures, registers, records, and evidence that shows how a Licensee understands its obligations, controls its risks and proves that its compliance arrangements are operating.
That sounds simple. (It’s not.)
For AFSL and ACL Licensees, compliance documentation is not just a folder of policies. It is the operating infrastructure that connects legal obligations, governance decisions, staff conduct, adviser behaviour, client outcomes, breach management and regulatory evidence.
A compliance manual explains the framework. Policies set expectations. Procedures explain the steps people must take. Registers capture decisions and events. Records show what happened. Evidence proves the system worked.
The distinction matters because ASIC does not assess compliance by looking for attractive documents. ASIC assesses whether the Licensee can show that it has adequate arrangements, that those arrangements are implemented, and that the business can prove what happened when it was tested.
What is compliance documentation?
Compliance documentation is the written and retained material a Licensee uses to design, communicate, operate, monitor and evidence its compliance framework.
It includes the documents that define the system and the records that prove the system was followed.
For an AFSL, the legislative foundation is section 912A of the Corporations Act 2001. That section requires an AFS Licensee to meet general obligations, including providing financial services efficiently, honestly and fairly, taking reasonable steps to ensure representatives’ compliance, maintaining competence, maintaining dispute resolution systems and adequate risk management systems. ASIC’s AFS licensee guidance also directs Licensees to RG 104 for information about compliance with those general obligations.
For an ACL, the equivalent foundation is section 47 of the National Consumer Credit Protection Act 2009. That section requires a credit Licensee to meet general conduct obligations, including engaging in credit activities efficiently, honestly and fairly, managing conflicts, taking reasonable steps to ensure representatives’ compliance, maintaining competence, having IDR procedures, and having adequate arrangements and systems to ensure compliance, including a written plan that documents those arrangements and systems.
Compliance documentation is how those (somewhat abstract) obligations become operational.
Why does compliance documentation matter?
Compliance documentation matters because compliance obligations are not self-executing.
A Licensee cannot simply point to the law and say its people know what to do. Nor can it rely on informal practice, corporate memory or the assumption that experienced staff will behave appropriately. Consider your documentation a “hope for the best, prepare for the worst”-type of situation
The documentation performs five functions.
First, it translates legal and regulatory obligations into business rules.
Second, it allocates responsibility so staff, managers, Responsible Managers, directors and representatives know what they are expected to do.
Third, it creates a consistent process for recurring obligations such as adviser reviews, complaint handling, breach assessment, CPD, representative onboarding, conflicts management and file remediation.
Fourth, it allows the Licensee to monitor whether the process is being followed (if you know what is supposed to happen, you can notice when it doesn’t).
Fifth, it creates evidence for ASIC, AFCA, auditors, boards, professional indemnity insurers and internal governance forums.
This is why compliance documentation should not be treated as a static compliance manual. It should be treated as part of the Licensee’s control environment.
What is the legislative context?
The legislative context differs between AFSL and ACL Licensees, but the practical expectation is similar.
An AFSL must have measures that allow it to comply with its general obligations. ASIC describes “compliance measures” in RG 104 as the processes, procedures or arrangements for ensuring, as far as is reasonably practicable, that the Licensee complies with its obligations. ASIC also states that what a Licensee needs to do depends on the nature, scale and complexity of its business.
An ACL must have adequate arrangements and systems to ensure compliance with its obligations under section 47, including a written plan that documents those arrangements and systems.
That difference is important.
For credit Licensees, the legislation expressly refers to a written plan documenting compliance arrangements and systems. For AFS Licensees, the documentation requirement is not neatly expressed in a single phrase, but it is still unavoidable in practice. A Licensee cannot demonstrate adequate supervision, training, risk management, conflict management, dispute resolution or compliance systems without documented arrangements and evidence of operation.
In both contexts, the question is not whether the Licensee has documents. The question is whether the documents are adequate, current, understood, implemented and evidenced (or: do they make sense and is the Licensee using them?).
What should a compliance manual do?
A compliance manual should explain the Licensee’s compliance framework.
It should not try to do everything.
A good compliance manual identifies the Licensee’s obligations, explains the governance structure, describes the key compliance systems and links to the supporting policies, procedures, registers and controls.
For an AFSL or ACL, a compliance manual commonly covers:
- licence authorisations and conditions;
- governance and accountability;
- Responsible Manager or key person obligations;
- representative appointment and supervision;
- training and competence;
- conflicts management;
- complaints and IDR;
- breach and incident management;
- advice or credit file review;
- advertising and marketing controls;
- privacy and information handling;
- outsourcing and third-party arrangements;
- recordkeeping;
- compliance monitoring and reporting;
- risk management; and
- regulatory change management.
The manual should not be an encyclopaedia. If it becomes too long, it becomes unusable. The manual should be the map. The policies and procedures should provide the details.
What is the difference between a policy and a procedure?
A policy states the rule (the What). A procedure explains how to comply with the rule (the How).
For example, a conflicts management policy might state that the Licensee must identify, assess, manage and record conflicts of interest. It may explain the Licensee’s approach to avoiding, controlling or disclosing conflicts.
The conflicts procedure should then explain who records the conflict, where it is recorded, who assesses it, what criteria are used, when it must be escalated, how controls are approved and how the register is reviewed.
This distinction is often lost.
Many Licensees have documents called policies that are actually procedures. Others have high-level policies but no practical workflow. The result is a framework that sounds right but can’t be reliably followed.
A defensible compliance framework needs both.
What are registers?
Registers are structured records of compliance events, decisions, risks or obligations.
They are important because they convert compliance activity into searchable, reviewable and reportable information.
Common registers include:
- breach and incident registers;
- complaints registers;
- conflicts registers;
- gifts and benefits registers;
- training and CPD registers;
- adviser or broker supervision registers;
- representative appointment registers;
- file review registers;
- remediation registers;
- regulatory change registers;
- outsourcing registers;
- vulnerable client registers;
- advertising approval registers; and
- board or compliance committee action registers.
A register is not useful just because it exists. It needs to capture the right fields, be updated promptly, reviewed regularly, and used for reporting.
A breach register, for example, should not just list incidents. It should record the date identified, issue description, obligation affected, assessment pathway, decision, reportability outcome, remediation, root cause, control failure, responsible owner, due date and closure evidence.
The register should help the Licensee answer the regulatory questions: what happened, why did it happen, what did we decide, what did we do, and how do we know it was fixed?
What are records?
Records are retained materials that show what occurred (which we all understand, because we know the importance of a thorough and well-maintained client file…).
They may include emails, meeting minutes, file notes, advice documents, credit assessments, review outcomes, call recordings, attestations, training completion reports, committee papers, client correspondence, remediation calculations, audit workpapers and system logs.
Records are different from policies.
A policy says what should happen. A record shows what did happen.
This distinction matters in complaints, adviser reviews, breach assessments and ASIC notices. A Licensee may have a good procedure, but if it can’t produce records showing the procedure was followed, the procedure’s practical value is unsubstantiated.
Poor recordkeeping also creates adverse inference risk. If a Licensee says it considered a matter but has no record of that consideration, the assertion may be difficult to defend (or: pics or it didn’t happen).
What is compliance evidence?
Compliance evidence is the subset of records that proves a compliance obligation, control or decision was performed. While it’s generally advisable to just record everything, not every record is useful evidence. Some records are incomplete, ambiguous, inconsistent or irrelevant.
Good compliance evidence is clear, dated, attributable, complete and connected to the obligation being tested.
For example, a file review report may be a record. It becomes useful compliance evidence when it shows the file reviewed, the criteria applied, the findings made, the rating given, the remediation required, the person responsible, the due date, the completion status and the closure evidence.
The relationship between documentation and evidence is simple.
Documentation says what the Licensee intended to do.
Evidence shows whether the Licensee actually did it (or: relevant pics or it didn’t happen).
What is document control?
Document control is the system used to ensure compliance documents are approved, current, accessible and reliable.
It should answer practical questions:
- Who owns the document?
- Who approved it?
- When was it approved?
- When must it be reviewed?
- What version is current?
- What changed from the previous version?
- Who needs to know about the change?
- Where is the authoritative version stored?
- Are obsolete versions removed from operational use?
- Is implementation tracked?
Without document control, Licensees can end up with multiple versions of the same policy, outdated templates, inconsistent procedures and staff relying on superseded guidance.
That creates operational risk. It also creates regulatory risk because the Licensee may not be able to show what standard applied at the relevant time.
What is version control?
Version control is a component of document control.
It records the history of a document, and should show the version number, date, author or owner, approver, summary of changes and effective date.
Version control matters because compliance obligations change. Business models change. ASIC guidance changes. Products change. Distribution models change. Technology changes. Staff roles change.
A document that was adequate three years ago may be inadequate now (actually, it will probably be, but I wouldn’t want to make assumptions).
A basic version control table should include:
| Version | Date approved | Approved by | Summary of change | Effective date | Next review |
| 1.0 | 1 July 2026 | Board | Initial approval | 1 July 2026 | 1 July 2027 |
| 1.1 | 15 September 2026 | Compliance Committee | Updated breach escalation procedure | 15 September 2026 | 1 July 2027 |
| 2.0 | 1 July 2027 | Board | Annual review and material restructure | 1 July 2027 | 1 July 2028 |
The table is not the point. The control is the point.
The Licensee must be able to identify the current document and explain why it is current.
What are examples of compliance documentation?
A practical AFSL or ACL compliance documentation suite may include the following:
- A compliance manual that describes the overall framework.
- A governance charter that explains board, committee, Responsible Manager, senior manager and compliance function responsibilities.
- A breach and incident policy that explains how incidents are identified, assessed, escalated, reported and remediated.
- A complaints policy and procedure that aligns with the Licensee’s IDR obligations and AFCA membership.
- A conflicts policy, conflicts procedure and conflicts register.
- A representative appointment and onboarding procedure.
- A training and competence framework.
- A supervision and monitoring program.
- An adviser or broker file review methodology.
- A remediation framework.
- An advertising and communications approval procedure.
- A privacy and data handling procedure.
- An outsourcing and third-party risk procedure.
- A regulatory change register.
- A compliance calendar.
- A board reporting template.
- A compliance committee pack.
- A document control register.
- A recordkeeping matrix.
- A compliance evidence register.
Together, these documents should explain what the Licensee does, who does it, when it happens, how it is recorded and how the Licensee knows (and shows) it has been done.
What is the relationship between compliance documentation and compliance evidence?
Compliance documentation and compliance evidence are related but not the same (think sisters, not twins).
Compliance documentation is the architecture. Compliance evidence is the proof.
A Licensee may have a breach policy, but ASIC will want to know whether incidents were identified, assessed and reported when required.
A Licensee may have a supervision framework, but ASIC will want to know whether representatives were actually supervised.
A Licensee may have a conflicts policy, but ASIC will want to know whether conflicts were identified, controlled and reviewed.
This is where many Licensees fall short; they confuse having a document with having evidence. The document is necessary, but rarely sufficient.
What makes compliance documentation effective?
Effective compliance documentation is practical, up to date, and used.
Documentation should be written for the people who need to apply it. It should reflect the Licensee’s actual business, not a generic (or aspirational) model. It should allocate responsibility clearly. It should connect to registers, workflows and reporting, and be reviewed when the world or the business changes.
Good documentation has five characteristics.
- It is accurate. It reflects current legal and regulatory obligations.
- It is tailored. It reflects the Licensee’s authorisations, services, products, distribution model, clients and representatives.
- It is operational. It explains what people must do, not just what the law says.
- It is controlled. The Licensee knows which version applies.
- It is evidenced. The Licensee can show that the document was implemented.
The test is simple.
- Could a competent person use the document to perform the task correctly?
- Could a manager use it to supervise the task?
- Could the board use it to understand the control?
- Could ASIC use the records to verify what happened?
If the answer is no, the document needs work.
What are common problems?
The most common problem is generic documentation.
Generic documentation creates a false sense of comfort. It may describe obligations correctly, but it does not explain how the Licensee actually complies.
Other common problems include:
- documents that do not match the Licensee’s business model;
- manuals that repeat legislation without practical steps;
- policies with no procedures;
- procedures with no owner;
- registers that are incomplete or inconsistently maintained;
- no evidence of review or approval;
- outdated document versions in circulation;
- templates that do not match current obligations;
- controls that are described but not performed;
- board reports that summarise activity without evidence;
- breach, complaint and conflict records that do not explain decisions;
- compliance calendars that are not linked to accountable owners; and
- poor storage, naming and retrieval practices.
These issues usually become visible when the Licensee faces a complaint, breach, file review, audit, due diligence request or ASIC notice.
That is a bad time to discover the framework is not defensible.
What should Licensees do now?
Licensees should review their compliance documentation as infrastructure, not administration.
Start with the core obligation map → Identify the obligations that apply to the business → Identify the document, control, register and evidence source that supports each obligation.
For each material obligation, ask:
- What document explains the requirement?
- What procedure explains the workflow?
- Who owns the obligation?
- What register captures the event or decision?
- What evidence proves the control operated?
- Who reviews the evidence?
- How is the issue reported to management or the board?
- When was the document last reviewed?
- Is the current version being used?
This exercise quickly reveals whether the compliance framework is real or cosmetic.
Key Insight
Compliance documentation is not paperwork. It is the operating system that allows a Licensee to control, evidence and defend compliance.
What this means in practice
For AFSL and ACL Licensees, compliance documentation should do more than satisfy a licensing checklist.
It should help the business make decisions, manage risk, supervise representatives, respond to complaints, assess breaches, brief the board and answer ASIC.
The practical issue is not whether the Licensee has a compliance manual.
Instead, the issue is whether the Licensee has a controlled, current and evidenced compliance framework that reflects the way the business actually operates.
Recommended next steps
Licensees should:
- create or update an obligation map;
- review the compliance manual against the current business model;
- separate policies from procedures;
- test whether each procedure has an owner, workflow, register and evidence source;
- review registers for completeness and decision quality;
- implement document control and version control;
- remove obsolete documents from operational use;
- test whether staff and representatives can find and use the current documents;
- align board reporting to evidence, not just activity; and
- schedule annual and event-driven document reviews.
Compliance documentation should make compliance easier to perform and easier to prove. If it does neither, it is not infrastructure; it’s decoration.
If your Licensee’s documentation is currently decorative, all is not lost. Reach out to our team, and we can review your documents and help you build a defensible, practical compliance infrastructure.
Found this article useful? You can select Assured Support as a ‘preferred source’ in Google. This may help you see more of our articles in Google Top Stories, AI Mode and AI Overviews when our content is relevant to your search.
Further Reading
Frequently Asked Questions
The most common weakness is the disconnect between documented expectations and operational evidence. Many licensees possess policies that accurately describe legal obligations, yet staff follow undocumented workarounds, registers are incomplete, remediation actions remain open, or document versions cannot be verified.
During an ASIC review or external audit, these weaknesses often become apparent because evidence cannot demonstrate that controls have been consistently operated.
Testing workflows, ownership and evidence quality usually reveals more than reviewing documents in isolation.
No. Technology improves administration, monitoring and evidence collection but cannot replace governance judgement or clearly documented obligations.
Compliance systems work best when they automate repeatable activities such as attestations, document control, register management, review scheduling and evidence collection, while leaving regulatory interpretation, risk assessment and governance decisions to appropriately authorised people.
Technology, therefore, strengthens compliance infrastructure rather than replacing it.
Boards are accountable for ensuring that governance arrangements remain effective, not merely for whether policies exist.
A board should therefore receive reporting that demonstrates controls are operating through measurable evidence—for example, completion rates, file review outcomes, breach trends, remediation progress and recurring control failures—not simply confirmation that policies have been updated.
This distinction helps directors exercise oversight over the effectiveness of the compliance framework rather than its documentation alone.
Not expressly.
ASIC expects AFS licensees to maintain adequate compliance arrangements capable of meeting their obligations under s912A, while RG104 explains that appropriate compliance measures depend on the nature, scale, and complexity of the business.
ACL holders have an additional statutory requirement to maintain a written compliance plan that documents their compliance arrangements under s47 of the NCCP Act.
The practical consequence is similar for both licence types: undocumented controls are difficult to supervise, review or evidence when challenged.
A large collection of documents does not necessarily indicate an effective compliance framework. Effective documentation is evidenced by whether staff understand it, apply it consistently and generate reliable records demonstrating that controls have operated as intended.
In practice, a useful test is whether a Responsible Manager, board member or regulator can follow a compliance obligation from legislation through to the relevant policy, procedure, register, operational record and evidence. Any break in that chain suggests the framework is incomplete. Documentation should therefore be assessed by its operational performance rather than its volume.
