The ACS RPL project report cyber security professionals submit is judged on one thing most templates ignore: whether you can show the reasoning behind your technical work, not just the work itself. Running a Nessus scan, triaging a SIEM alert, or scoping a red-team engagement, experienced practitioners do all of that in their sleep. Turning that experience into Australian Computer Society (ACS) format is a different skill, and it trips up practitioners who have the years but no local ICT degree. This guide covers the whole report for security roles: which occupation code to claim, which projects qualify, and how to write about work you signed an NDA to protect.
ANZSCO 262112 vs 262118: Choose the Code First
Recognition of Prior Learning (RPL) is the ACS pathway for applicants whose experience, rather than a formal ICT qualification, carries their skills assessment. Before you write a single project paragraph, decide which occupation you are claiming. That choice changes the lens the assessor reads you through.
Most guides conflate the two codes; here is the distinction that changes how your report is read. ACS's cyber security occupations list contains seven codes: 261315, 261317, 262114, 262115, 262116, 262117, and 262118. ANZSCO 262112 (ICT Security Specialist) is not among them. ACS classifies 262112 under its broader IT occupations, while 262118 (Cyber Security Operations Coordinator) sits on the dedicated cyber security list. So a 262112 report is read against general ICT competency, with security as your area of specialisation, whereas a 262118 report is measured against cyber-security-specific expectations from the start. Same career, two different measuring sticks.
One more code is worth knowing: 261317 is Penetration Tester. If offensive security is genuinely your full-time role, that code may fit your evidence better than either of the two this guide compares. For most security specialists and operations leads, the real decision is 262112 versus 262118, and it comes down to what your projects actually demonstrate.
Project type | Stronger code |
|---|---|
Penetration testing, vulnerability assessment | 262112 (or 261317 for a dedicated pen-test role) |
SIEM deployment, security architecture review, network security hardening | 262112 |
SOC implementation and operations, incident response, threat hunting | 262118 |
Cross-team incident coordination, forensic evidence handling | 262118 |
This mapping is our reading of ACS's published occupation descriptions, not an ACS rule. Use it to see which code your strongest evidence points to, then commit before you draft.
What ACS Wants in a 262112 ICT Security Specialist Report
Because 262112 sits under IT occupations, the assessor expects security competence framed inside broad ICT capability. Design and build work reads well here: specifying controls, architecting a segmented network, hardening a cloud estate, standing up a vulnerability management programme. Show that you scoped a problem, chose an approach, and owned the technical outcome. Security depth still matters, but position it as your specialisation within solid ICT engineering, not as an isolated skill.
What ACS Wants in a 262118 Operations Coordinator Report
ACS's own description of 262118 has the coordinator leading responses to complex cyber security incidents and threat hunting investigations while managing tasks across several teams. Listed duties run through incident investigation and containment, security risk analysis, threat modelling, team coordination, security awareness support, and forensic evidence collection. A strong 262118 report therefore shows leadership and orchestration, not only hands-on tooling. Evidence that reads mostly as "I configured the SIEM" belongs in a 262112 report. Evidence that reads as "I ran the containment, tasked three teams, and owned the post-incident review" belongs in a 262118 report.
What to Gather Before You Write
Good reports are assembled, not remembered. Pull your material together first, and you will write faster and hedge less.
Project Records and Documentation You Will Need
For each candidate project, collect the timeline, your job title and reporting line, the environment (cloud, on-premises, or hybrid), the tools in play, the methodology you followed, and the outcome you can defend. You do not attach the client deliverable itself. What you need is enough factual scaffolding to write a truthful narrative in your own words: dates, your specific responsibilities, the decisions you made, and metrics you would stand behind if questioned.
Handling Projects Covered by NDAs
An NDA does not disqualify a project. Write at the level of methodology, threat model, and outcome, and strip the identifying detail: no client name, no specific CVEs you exploited, no proprietary configurations or architecture diagrams. "A mid-size financial services firm running a hybrid AWS and on-premises estate" tells the assessor everything they need and breaches nothing. Keep the abstraction and describe your reasoning rather than the client's secrets.
Step 1: Pick Two Projects Where Security Was the Core
ACS RPL requires two project reports. Choose engagements where security was the point of the work, not a side effect of it.
Cyber Security Project Types ACS Accepts
Security work spans plenty of accepted shapes: penetration testing, vulnerability assessment, SIEM deployment, incident response, security architecture review, SOC implementation, and network security hardening. Each can carry a report on its own if you were a decision-maker in it. A penetration test shows offensive methodology and risk prioritisation. A SIEM deployment shows detection engineering and data-source design. An incident response case shows containment judgement under pressure. Pick the two that let you show the most of your own reasoning, and lean toward variety so the pair reads as range rather than repetition.
Recency and Scope: What Makes a Project Count
Get the recency rule right, because almost every competing page gets it wrong. ACS's RPL pathway page states that you submit one project completed within the last two years and one from within the last four years. Pages citing three-and-five-year or three-and-eight-year windows are recirculating an error; the figures to follow are the two-year and four-year ones on acs.org.au. On scope, the project has to put you in a security decision-making seat. If you sat on the edge of someone else's engagement, it will not carry a report, however interesting the work was.
Step 2: Set the Project Context and Define Your Role
Every report opens by orienting the assessor, then quickly narrows to you. Context earns its place only when it sets up the decisions you go on to describe.
Describing the Organisation Without Naming Clients
Describe the organisation by the attributes that shaped your technical choices: sector, rough size, regulatory pressure, and the environment you worked in. "A national retailer processing card payments across a hybrid estate" gives the assessor the constraints behind your decisions without naming anyone. Resist the urge to add colour that adds risk. The identity of the client is never assessed; your judgement is.
Separating Your Work From the Team's Work
ACS assesses you as an individual, so the boundary between your contribution and the team's has to be sharp. Use "I" for what you decided and did, and reserve "we" for genuine shared work you then break down. If you led the containment but a colleague ran forensics, say so. Assessors have read enough reports to spot borrowed credit, and a vague "the team implemented" line where your own action should be leaves them unable to score you.
Step 3: Document Tasks, Tools, and the Decisions Behind Them
This is where most cyber security reports live or die. Listing tools is easy. The reasoning behind them is what ACS is actually reading for.
Security Tools ACS Assessors Recognise by Name
Name the real tools. Assessors recognise Nessus, Burp Suite, Splunk, Wireshark, CrowdStrike, Metasploit, AWS Security Hub, and Qualys, and a report that stays abstract about tooling reads as thin. The name alone proves nothing, though. "I ran Nessus scans" is task execution, the kind of line a junior could write. "I selected Nessus over Qualys because the target environment was on-premises with no internet egress, which ruled out Qualys's cloud-relay scanning" is technical decision-making, and it demonstrates the professional-level competency ACS grades. Attach a reason to every significant tool: what you chose, what you rejected, and why the environment made the difference.
How Much Technical Depth Each Section Needs
Around 1,000 words per project is a commonly cited benchmark; ACS does not publish a fixed count, so treat it as a target for completeness rather than a rule to pad toward. Spend the words unevenly. A routine step gets a sentence. The decision that shaped the whole engagement, the trade-off you weighed, the constraint that forced your hand, earn a full paragraph. Depth here means the chain of reasoning, not more adjectives. Any paragraph that does not show a choice you made is probably filler.
Step 4: Record Outcomes and Show Security Knowledge
A report that stops at "the work was completed" leaves marks on the table. Close each project by proving the result and connecting it to recognised knowledge.
Framing Outcomes Without Exposing Client Vulnerabilities
State outcomes in terms of the class of weakness you addressed and the control you introduced, not the exploit chain that got you there. "Closed a privilege-escalation path in the identity layer and cut the remediation backlog to zero within the engagement window" reports a real result without handing anyone a map to the client's old flaws. Where you cite a metric, use one you can defend from your own records; do not invent a percentage to look impressive. A modest, honest figure beats a precise-sounding one you cannot back.
Linking Your Work to ACS CBOK Security Topics
Competitors tell you to "align with the Core Body of Knowledge (CBOK)" and stop there. Point to the relevant knowledge areas instead. For security roles, the primary area is the ACS CBOK security management topic. Support it with the CBOK areas covering information assurance and network security. Map your work to them in plain prose: a SOC or SIEM build leans on the information assurance and security management areas; a network hardening project on network security; an incident response case on security management. You are not quoting the CBOK at the assessor. You are showing that your practical work maps cleanly onto the knowledge they expect.
Self-Audit Checklist Before You Lodge
Run every ACS RPL project report cyber security applicants prepare through this list before submission:
Both projects fall inside the correct windows: one within two years, one within four.
The occupation code matches the evidence (262112 for specialist build-and-design work, 262118 for operations and incident coordination).
Every named tool carries the reason you chose it, not just the fact you used it.
No client is named, no specific CVE is disclosed, and no proprietary configuration appears.
Your individual contribution is unmistakable in every section.
Outcomes are stated with defensible metrics or honest qualitative results.
The writing is entirely your own. ACS uses plagiarism detection on RPL submissions, so the report must be in your own words throughout.
Why Cyber Security RPL Reports Fail at ACS
Most rejections trace to two habits, and both are avoidable once you know what the assessor is grading.
Listing Tools Without the Reasoning Behind Them
The most common failure is a report that reads like a resume of technologies: Splunk, CrowdStrike, Wireshark, Metasploit, all present, none explained. Enumeration signals exposure, not competency, and competency is the bar. Every tool that mattered needs the decision attached to it, or it is doing nothing for your assessment except filling space.
Projects Where Security Was Incidental
Choosing a project where security was a minor thread in a bigger IT effort is the second failure. If you spent 90 percent of the engagement on a migration and 10 percent tightening firewall rules, that is not a cyber security project, and framing it as one invites doubt about the whole application. Pick engagements where security was the reason the work existed, and the rest of the report becomes easier to write.
FAQs
Can I use a penetration testing engagement as my ACS RPL project if I signed a client NDA?
Yes. A penetration test under NDA is acceptable as long as you write it at the methodology and outcome level. Describe your scoping, threat model, testing approach, and the classes of finding you remediated, without naming the client, disclosing specific CVEs, or reproducing proprietary configurations. The confidentiality holds and the report still shows your reasoning.
Does ACS assess ANZSCO 262112 and 262118 differently when reviewing project reports?
Yes. 262112 (ICT Security Specialist) sits under ACS's IT occupations and is read against broader ICT competency with security as your specialisation. 262118 (Cyber Security Operations Coordinator) appears on ACS's dedicated cyber security occupations list and is read against cyber-security-specific expectations around incident response and coordination. Choose the code your evidence fits before you draft.
Do I need to name the specific security tools I used, like Nessus or Splunk, in the report?
Yes, and you should. Assessors recognise tools like Nessus, Splunk, Burp Suite, and CrowdStrike, and naming them grounds the work. The name alone is not enough, though. Pair each significant tool with the decision behind it: why you chose it over the alternative, given the environment.
Can I combine several smaller incident response cases into one RPL project report?
You can, but do it carefully. A loose stack of unrelated tickets reads as fragmented and weakens your individual-contribution story. If several cases genuinely formed one coordinated programme, for example, a ransomware response with distinct phases, present them as a single engagement with a through-line. Otherwise, pick the one strongest case and write it in depth.
What if my only experience is SOC monitoring and I have no standalone project to write about?
ACS accommodates this: its RPL pathway page notes that applicants not in project-based roles may substitute a description of their work experience and the challenges they faced. As a SOC analyst, document a sustained body of work such as a detection-tuning effort or a recurring incident-handling responsibility, and treat the decisions and outcomes within it the way you would treat a project.
How recent does a cyber security project need to be to count toward ACS RPL?
One of your two reports must cover a project completed within the last two years, and the other within the last four years, per ACS's RPL pathway page. Ignore the three- and five-year figures on competitor sites; they contradict the current ACS guidance.
If you are still deciding which engagements to write up, read our guide on choosing the right projects for your ACS RPL report. Our cyber security RPL project writing service reviews the drafts you have written and provides feedback before you lodge.