Field guide
The board asked. Here's how to answer.
In August 2026 the Australian Signals Directorate and the Australian Institute of Company Directors published guidance for boards on frontier AI cyber threats. It gives directors questions to put to management. This is a practical guide to answering them.
The questions land on you
The guidance tells directors to put a set of threshold questions to management, and to challenge the answers with regular reporting and assurance. Do you have the answers?
Some of those questions have an answer already sitting in your systems. Others need work that has not started, or evidence you could not produce this week if somebody asked for it. Knowing which is which before the meeting is most of the job.
The ASD document is public, short and worth reading in full. What follows is the layer underneath it: for each priority, what a good answer looks like and how to get there.
Three capabilities that change the threat
Speed and scale
Vulnerability discovery and exploitation timelines collapse from days to hours.
Chaining
Minor weaknesses that no alarm would fire on individually get combined into major compromises.
A lower skill floor
Attackers who previously lacked the technical knowledge can now reach it, so the pool of credible threat actors has grown.
These developments “may rapidly invalidate organisations’ current risk tolerance.”
Two minutes
Can you answer the six questions?
Each one has an evidence test attached, so a yes has to be earned. Answer them and you will know which questions you can already field and which need work, before somebody asks.
1. Vendor control
3 pointsDo you know who owns and controls the AI your organisation uses?
Only count a yes if: For every AI tool in use: the operating entity, its country of incorporation, where your data is processed, whether a foreign government could compel access, and what your exit looks like.
2. Visibility
2 pointsDoes your list of AI tools come from a system, or from asking people?
Only count a yes if: Sign-in logs, expense records, network or browser telemetry, or SaaS discovery. Not a staff survey.
3. Privilege
3 pointsCan you say what each AI tool and agent is allowed to reach?
Only count a yes if: A named owner, permissions explicitly granted rather than inherited, a list of what it can read and write, and somebody reviewing that list on a schedule.
4. Evidence
3 pointsCould you produce a record of AI use if a regulator asked tomorrow?
Only count a yes if: Who used which tool, for what, and what categories of data were involved, over a period you did not choose in advance, without building it first.
5. Speed
2 pointsHas your incident response plan been exercised, not just reviewed?
Only count a yes if: Exercised within the last twelve months, and at least one exercise involved an AI tool or agent.
6. Assumptions
2 pointsDo you know which assumptions in your risk register have stopped being true?
Only count a yes if: You can name at least two specific assumptions and say whether they still hold.
0 of 6 answered
Eight priorities, in ASD's own order
Every priority ASD names, matched with what you need to answer it: what good looks like, how to get there, and where ORCA Opti helps.
Immediate priorities
Secure attack surfaces
What ASD asks
“Systems are securely configured to approved and maintained baselines, with configurations continually monitored and consistently enforced.”
What good looks like. You have a written configuration baseline. It is deployed rather than aspirational. And you find out when something drifts from it without anyone having to go looking.
Do it yourself
- Define approved baselines that disable or remove unnecessary services, insecure settings and unsupported protocols.
- Deploy them across infrastructure, operating systems and applications, through Intune or equivalent.
- Set up drift detection. This is the step most organisations skip, and it is the one ASD explicitly names.
- Decide who reviews drift, how often, and what happens when they find it.
What changes with ORCA Opti
Steps one and two are yours. Nobody can write your baseline for you and no platform deploys it on your behalf. Step three is what Opti Cyber does: automated checks against your Microsoft 365 environment on a schedule, showing configuration drift as it happens, with each result written back as dated evidence against the control it tests. The answer to “how do you know?” stops being “we check periodically” and becomes a record with timestamps on it.
Reduce software vulnerabilities
What ASD asks
“Vulnerabilities are identified, documented, validated and prioritised for remediation in a timely manner, with all remediation verified for effectiveness.”
What good looks like. You know your patch compliance rate as a number, you know your risk-based timeframes, and you can show that remediation actually worked rather than that a ticket was closed.
Do it yourself
- Run continuous, repeatable vulnerability scanning rather than point-in-time assessments.
- Define risk-based remediation timeframes and write them down, so “timely” means something specific.
- Apply patches within those timeframes, automatically where operational impact is low.
- Verify remediation. A closed ticket is not evidence that the vulnerability is gone.
What changes with ORCA Opti
Opti Cyber gives you the number and keeps it current: operating system patch compliance against a target, critical application patch monitoring gaps, both recorded as dated evidence so the trend is visible over time. That answers the two questions your board will actually ask, which are what the number is and whether it is improving. It sits alongside the endpoint management tooling that deploys the patches themselves.
Short term priorities
Replace legacy systems
What ASD asks
“Systems that cannot meet cyber security requirements are managed using compensating controls, with enhanced monitoring, until they can be decommissioned or replaced.”
What good looks like. You have a list. Each item on it has a compensating control, an owner, and either a replacement date or an explicit, documented decision to accept the risk.
Do it yourself
- Identify legacy systems that cannot meet your baseline. Be honest about the ones nobody wants to touch.
- Assess what each one is exposed to.
- Apply compensating controls and increase monitoring around them.
- Put a decommission or replacement plan against each, with a date, and take the ones without a date to your board as accepted risk.
What changes with ORCA Opti
Opti Core holds the legacy register, tracks the compensating controls applied to each system, and raises the review task on a schedule so nothing sits unexamined between board meetings. Where a system is accepted as a residual risk, that decision is recorded with an owner and a date, which is exactly what a director will ask to see. The replacement decisions and the budget behind them stay part of your own architecture planning.
Reinforce identity, credential and access management
What ASD asks
“Robust and secure identity, credential and access management is used to establish, maintain and control access to systems, and to support effective detection of identity and credential misuse.”
What good looks like. Phishing-resistant multi-factor authentication for everyone, not just admins. Legacy authentication protocols disabled. Credentials unique per system. Secrets stored properly and nothing sensitive sitting in a file share.
Do it yourself
- Enforce phishing-resistant MFA for all users authenticating from untrusted, external or high-risk locations. ASD names phishing-resistant specifically, so app-based codes are not the finish line.
- Disable legacy authentication protocols. They bypass modern controls entirely and they are the most common way MFA gets stepped around.
- Identify and remove default and unused accounts on a schedule.
- Store authentication keys, secrets and tokens in approved repositories with access controls.
- Regularly scan codebases, configuration files, file shares and collaboration platforms for unsecured credentials.
What changes with ORCA Opti
Configuration is yours. What Opti Cyber adds is that the first three stop being things you believe and become things you can show: MFA policy enforcement, MFA on privileged accounts, legacy authentication status, global administrator counts and privileged account ratios, each checked on a schedule and each producing dated evidence. The useful consequence is the one nobody expects. A control can be marked Implemented by your team and Ineffective by the automated check, on the same row, at the same time. That gap is what an auditor finds and what a board never sees.
Restrict unnecessary privileges
What ASD asks
“Personnel and services, including AI agents, are granted the minimum access to systems required to undertake their duties.”
What good looks like. Every AI tool or agent with access to a system has a named owner. Its permissions were explicitly granted rather than inherited from whoever connected it. You can produce the list of what each one can read and write. Somebody reviews that list on a schedule.
Do it yourself
- For people: review and update access privileges against current roles, restrict account and role administration to authorised administrators, and provision every account with minimum privilege.
- For AI agents, start with your tenancy's consented applications. This is where an agent most often holds standing access nobody has reviewed.
- Write down, for each agent, what it can read and what it can write. Most organisations discover at this point that they cannot answer it.
- Put the review on a schedule with an owner.
What changes with ORCA Opti
This is the section where the answer is substantial. AI Guardian inspects every AI interaction at three points: the message going in, the response coming back, and any action an agent proposes to take. That third checkpoint can block an action or hold it for human approval, which is what minimum access means at runtime rather than in policy. Separately, when you turn a documented procedure into an automation, ORCA produces a proposal before anything is created: how many steps can be automated, how many require a person, and only the tools the automatable steps actually need. The agent is created as a draft, acts on reads, and seeks approval before writes.
Prepare for cyber security incidents
What ASD asks
“Incident response, business continuity and disaster recovery plans support continued operations during incidents and resumption afterwards. ASD lists exercising the plans as a separate priority from having them.”
What good looks like. The plans exist, they are current, they have been exercised in the last twelve months, and at least one exercise involved an AI tool or agent.
Do it yourself
- Review your incident response, business continuity and disaster recovery plans against what you actually run now.
- Exercise them. Reviewing a document is not exercising a plan.
- Include a scenario involving an AI tool or agent, because your existing scenarios almost certainly do not.
- Record what the exercise found and what you changed.
What changes with ORCA Opti
Partial, and worth being precise about. The plans live in Opti Core as documents with an owner, an approver, version history and a review cycle that raises its own tasks and escalates when they go overdue, so current becomes verifiable rather than assumed. Incidents are recorded with regulatory and contractual impact rated against each one, and an incident can be raised automatically from a failed check. Running the exercise is still your job. Nothing schedules the room and gets people into it.
Medium term priorities
Adopt AI for cyber defence
What ASD asks
“Artificial intelligence is used for cyber defence and is secure, controllable, human-supervised and used in an ethical and accountable manner.”
What good looks like. You can say which AI systems you run, who owns each, what risk level each carries, and what a person is required to approve. You can produce a record of AI use if asked. And your AI has a defined threat model rather than a vendor's assurance.
Do it yourself
- Build an inventory of AI systems in use, sourced from telemetry rather than a staff survey. Self-reported AI use is always wrong in the same direction.
- Define what your AI is not permitted to do, and where a human must approve.
- Establish a threat model. The OWASP Top 10 for Large Language Model Applications and MITRE ATLAS are both public, maintained and free, and they are a better starting point than anything you will write from scratch.
- Decide how you will detect prompt injection, data extraction attempts and system prompt leakage, and what happens when you do.
- Keep a retained record of AI use that you could produce for a regulator.
What changes with ORCA Opti
AI Guardian is built for exactly this. Its detection taxonomy is mapped to the OWASP LLM Top 10 and MITRE ATLAS rather than to a list we wrote, and where a listed risk sits outside the scope of runtime inspection we say so and say where it is handled instead. The human supervision ASD asks for is written into the system agents themselves: they are instructed never to invent meetings, people, numbers or deadlines, to show a draft before sending anything and send only on explicit confirmation, and never to make a financial, legal or contractual commitment on a person's behalf. Those are instructions you can read in the interface, not promises in a datasheet.
Longer term priorities
Modernise for the future
What ASD asks
“Systems are planned, designed, developed, tested, deployed, maintained and decommissioned according to business criticality, using Secure by Design and Secure by Default principles.”
What good looks like. Security requirements enter at design rather than at review. Build and deployment processes enforce controls consistently. Systems are designed to give visibility, enforce authorised access, protect data, minimise default privileges and remove unnecessary functionality.
Do it yourself
- Read the ASD Secure by Design material directly. It is more useful than any summary, including this one.
What changes with ORCA Opti
Opti Core holds the standard you have adopted, records which projects were assessed against it and what each assessment found, so secure by design becomes something you can evidence rather than assert. The engineering practice sits with your delivery teams, and the platform is where the record of it lives.
Where it gets difficult
The three questions organisations most often cannot answer
“Are we relying on vendors and service providers without sufficient governance and oversight, including an understanding of their foreign ownership, control or influence?”
This is asked twice in the guidance, and almost nobody can answer it about their AI vendors specifically. For every AI tool in use you need the operating entity, its country of incorporation, the jurisdiction your data is processed and stored in, whether a foreign government could compel access and under what instrument, and what your exit looks like. An unknown vendor is a worse answer than an offshore one, because it means nobody has looked.
“Do we have control over our cyber security fundamentals, such as adherence with a recognised cyber security framework?”
The trap here is presenting a monitoring result as an assurance result. A scan saying a control passed is not a person attesting to it. If your board asks for maturity, give them both numbers and explain the difference, even when the assessed figure is lower than the monitored one. That is the honest answer and it is also the one that survives an audit.
“How vulnerable is our organisation to AI-enabled attacks?”
You cannot answer this from a survey. If your list of AI tools came from asking people rather than from sign-in logs, expense records, browser telemetry or SaaS discovery, treat it as a floor and tell your board that is what it is. Naming the limit is a stronger answer than a confident number you cannot support.
See what you could evidence today
Questions one, three and four are the ones organisations most often cannot answer, and they are the three that need a record produced continuously rather than assembled after the fact. The readiness assessments are free for one user, with no credit card and no administrator approval needed to start.
Quotations are from Frontier AI cyber threat considerations for boards of directors, Australian Signals Directorate and Australian Institute of Company Directors, published August 2026, used under Creative Commons Attribution 4.0. This guide is ORCA Opti's reading of that published guidance. Neither ASD nor the AICD has reviewed, approved or endorsed this document, ORCA Opti or any commercial product. This guide is general in nature and is not legal advice.