I Think We’ve Been Hacked — What Do I Do First?

By BCyber Security Team | CISSP, CISM Last updated: 15 October 2026

If you think you’ve been hacked, the first move is not cleanup — it is containment.

In our incident-response work, the most common early mistake is trying to “fix” the obvious symptom before the full attack path is understood. That can destroy evidence, trigger re-compromise, or widen the blast radius. Whether the issue is a suspicious Microsoft 365 login, a finance mailbox compromise, a stolen VPN session, or a ransomware alert, the first question is the same: how do we stop further damage while preserving proof of what happened?

This guide is written for Australian organisations, especially teams operating under frameworks such as the Essential Eight, NIST Incident Response lifecycle, ISO 27001, and sector obligations like APRA CPS 234. If you are in financial services, healthcare, or government, those obligations can affect both how quickly you act and what you may need to report.

At BCyber, we typically align first-response actions to our GRACE Portal visibility model:

• Governance: who approves response decisions
• Risk: how bad the impact could be
• Assurance: what evidence must be preserved
• Compliance: which legal or contractual obligations may apply
• Execution: what to do next, in what order

Our platform inventory includes 23 policies, 9 processes, 50 courses, 995 published articles, 574 knowledge hub entries, 11 clients, and 15 fact-find assessments. These figures are current at the time of publication and are provided to help readers understand the maturity of our internal knowledge base; they should be interpreted as operational context, not a guarantee of outcome.

What should I do in the first few minutes?

If you are asking, “I think we’ve been hacked — what do I do first?”, the answer is simple: stop the attacker from continuing.

That means containment before remediation. In practice, that can mean revoking active sessions, isolating endpoints from the network, disabling compromised accounts, or pausing a suspicious payment workflow. The goal is to slow attacker movement while keeping enough clean systems online to continue operating.

For organisations in financial services, this is often the moment a suspicious finance mailbox or shared approver account needs urgent review. In healthcare, it may be a compromised receptionist or clinical admin account with access to patient data. In government, it may be a cloud tenant or identity provider account that can reach records across multiple systems. In all three, speed matters — but so does preserving evidence.

Contain first, clean up later

Containment is about cutting off access paths, not proving the whole story in the first five minutes. A rushed password reset on a compromised machine can overwrite useful forensic artefacts, and powering down the wrong server can make recovery harder than it needs to be.

A better approach is:

1. Identify the most likely entry point.
2. Stop active access.
3. Preserve logs and session data.
4. Confirm the scope before broad changes.

That sequence mirrors established incident-response practice in NIST SP 800-61 Rev. 2 and is consistent with the ASD Essential Eight, where identity hardening and application control are part of reducing attacker persistence.

Isolate accounts, devices, and cloud services

Start with the most privileged or most exposed asset first:

• revoke active sessions
• remove unknown MFA devices
• disable rogue OAuth grants or API tokens
• reset passwords from a clean device
• quarantine suspicious endpoints
• suspend untrusted inbox rules or forwarding rules

If a device looks infected, disconnect Wi-Fi and Ethernet, but do not reuse that device to log into sensitive services. If the issue is in Microsoft 365, Google Workspace, or another SaaS platform, inspect:

• inbox rules
• mailbox forwarding
• delegated access
• OAuth consent grants
• app passwords
• service principals and API tokens

In BCyber’s CyberTriage workflow, this is the point where a rapid 4-minute triage can help determine whether the event is a suspicious login, a business email compromise, or a broader intrusion. That triage supports the Execution and Assurance pillars in GRACE by turning a noisy alert into a prioritised response path.

Keep business continuity in view

Containment should be targeted, not chaotic. A full shutdown can be worse than the incident itself, especially for regulated operations that must continue under controlled conditions.

A financial services team may temporarily restrict payments above a threshold and require out-of-band verification. A healthcare provider may isolate a compromised admin workstation while keeping clinical systems available. A government team may disable external sharing on a tenant while preserving internal access for essential staff.

The principle is straightforward: stop attacker movement without turning the response into a self-inflicted outage.

If the first alert is an MFA prompt, an unusual login, or a strange invoice, assume it may be a symptom rather than the whole incident.

How do I preserve evidence without making things worse?

Evidence is the forest floor of the incident: once disturbed carelessly, it becomes much harder to read what really happened.

Under Australian privacy, regulatory, and contractual frameworks, good evidence handling matters because you may need to explain not just what was attacked, but what you did next. That could affect legal advice, cyber insurance, regulator reporting, and internal governance.

Start an incident log immediately

Record:

• who noticed the issue
• when it was first observed
• what was seen
• which systems were touched
• what actions were taken
• who authorised each action

Keep the language factual and chronological. Mark uncertain items as unconfirmed.

BCyber’s process-driven response approach and knowledge assets support this style of documentation. Our published guidance is structured to help teams map actions to repeatable processes rather than ad hoc decisions — especially where Compliance Tracking and Executive Reporting are needed through the GRACE Portal.

Save evidence before it disappears

Preserve:

• email headers
• suspicious messages
• login alerts
• screenshots
• ransom notes
• log exports from identity providers
• EDR telemetry
• firewall/VPN logs
• cloud audit logs
• bank references and approval trails

If payments or fraud are involved, preserve:

• beneficiary changes
• invoice metadata
• approval records
• timestamps
• sender identities
• call-back verification notes

Do not delete suspicious messages “to clean up inbox noise.” Do not test malware on a production machine. Do not rebuild before capturing what you can. In healthcare and government environments, where auditability is critical, this can become a governance issue as much as a technical one.

Write down actions as they happen

Your log should show:

• action taken
• who approved it
• when it happened
• why it happened

This is especially important if the incident later becomes subject to:

• APRA review
• insurer questions
• board reporting
• privacy or breach notification
• contract dispute resolution

BCyber’s Paradigm GRC platform is designed to help organisations map these events to policy, risk, and compliance obligations. In a mature response, the incident record should line up with policy controls, not sit separately from them.

How do I tell what actually happened?

The first alert rarely tells the whole story.

A suspicious login could be a benign admin action, a security tool, or the start of account takeover. A strange invoice could be a one-off error or a business email compromise. A ransomware note could be the visible stage of a compromise that started days or weeks earlier.

Identify the type of incident

Classify the event into a working category:

• suspicious access attempt
• account takeover
• malware infection
• ransomware
• business email compromise
• data exposure
• insider misuse
• third-party compromise

This matters because each category changes:

• containment steps
• evidence requirements
• notification urgency
• recovery order

For example, if you are seeing:

• MFA fatigue prompts
• unusual geographic logins
• inbox rules
• delegated mailbox access
• OAuth consent abuse

then account takeover is likely. If you see:

• file encryption
• inaccessible systems
• ransom demand
• shadow copy deletion
• disabled backups

then you may be in ransomware territory and need a different response path entirely.

Map the affected assets

Build a quick list of:

• user accounts
• privileged accounts
• endpoints
• cloud services
• finance workflows
• shared drives
• third-party integrations
• API keys and service accounts

In larger environments, one compromised identity can move across SaaS applications, remote access, and business systems if conditional access and privilege controls are weak. This is exactly where the Essential Eight and ISO 27001 control environment matter: patching, MFA, least privilege, application control, and regular backup testing all reduce the chance that one incident becomes many.

BCyber’s Profiler behavioural intelligence platform is relevant here because it can help identify:

• access anomalies
• unusual user behaviour
• insider threat patterns
• out-of-pattern administrative actions

That behavioural layer is often what distinguishes a simple login issue from a true compromise.

Look for attacker activity

Check for:

• new admin roles
• inbox forwarding rules
• mailbox delegation changes
• unusual API use
• archive creation
• bulk downloads
• abnormal synchronisation
• impossible travel logins
• token replay
• suspicious service account activity

If a cloud tenant is involved, review:

• audit logs
• conditional access events
• external sharing settings
• OAuth grants
• service principal changes
• device compliance states

If lateral movement is suspected, the incident is broader than one mailbox or one endpoint. At that point, a structured investigation matters more than speed alone.

Establish the likely entry point

Common paths include:

• phishing
• reused passwords
• MFA push bombing
• vulnerable remote access services
• exposed credentials
• misconfigured cloud storage
• compromised third-party access
• privilege misuse

If the attack came through weak identity hygiene, password resets alone are not enough. If the root cause is a misconfigured share or exposed token, identity-only remediation will miss the real problem.

That is why BCyber’s Perfect Storm scenario intelligence is useful in tabletop and war-gaming contexts: it helps teams test how a likely entry point could cascade into a broader compromise.

How do I protect money, people, and essential operations?

Once the incident is contained and the likely scope is clearer, protect the systems that can do the fastest harm: identity, finance, and operational platforms.

Lock down identity and access

From a clean device:

• reset credentials
• revoke active sessions
• remove unknown devices
• enforce MFA
• review privileged roles
• rotate API keys and secrets
• invalidate recovery codes where needed

If an administrator account was involved, treat the environment as high risk until you verify privilege has not been expanded or persistence created through hidden groups, delegated access, scheduled tasks, or service accounts.

This aligns with the ASD Essential Eight and with common NIST and ISO 27001 response expectations around access control, logging, and recovery.

Protect banking and payment workflows

If there is any sign of:

• invoice fraud
• payroll diversion
• supplier redirection
• payment change requests
• executive impersonation

then involve finance immediately.

Practical steps include:

• freezing suspicious transfers where possible
• verifying beneficiary changes out of band
• confirming account details using a trusted number
• reviewing recent approval changes
• checking shared finance inboxes
• auditing automated approval flows

In financial services, this may also involve stronger maker-checker controls and heightened fraud monitoring. In healthcare, it may include supplier invoice verification where compromised email accounts could redirect procurement. In government, procurement and payment integrity controls should be checked against delegated approval rules.

Stabilise the most important operations

Not every system needs equal treatment during a crisis.

A useful question is: what must keep running, and what can be temporarily constrained?

Examples:

• restrict external sharing
• pause non-essential admin changes
• move to manual approval for high-risk transactions
• segment a compromised network zone
• restrict remote access to trusted devices only

This is where BCyber’s GRACE Portal can help by providing:

• a single dashboard
• cross-product analytics
• executive reporting
• compliance tracking
• real-time monitoring

That matters because executive decisions during a breach are often made with incomplete information. A centralised view reduces the chance of contradictory instructions across teams.

Keep staff and customers informed carefully

People need clear instructions, not speculation.

Tell staff:

• what suspicious activity to watch for
• which channel to use for incident updates
• who to contact if they see fake payment requests
• what not to do, such as forwarding unverified alerts or changing settings themselves

If customer data or service disruption may be involved, prepare a factual holding statement. Keep sensitive discussions to need-to-know channels.

Could this trigger Australian legal or notification obligations?

Yes — and you should ask early, not after the full technical investigation is finished.

Australian obligations may arise under:

• the Privacy Act 1988 and Notifiable Data Breaches scheme
• APRA CPS 234 for regulated entities
• state or territory health records obligations
• critical infrastructure requirements
• contractual notification clauses
• government security and record-handling requirements

Watch the data types closely

The urgency changes if the incident involves:

• personal information
• sensitive information
• health records
• financial records
• payroll or tax data
• confidential government information
• credentials or identity data
• regulated operational data

Access alone may matter, but exfiltration increases risk significantly. If data could reasonably have been read, copied, or used by an unauthorised party, legal and compliance review should be treated as part of the response.

Check Australian obligations early

Relevant references include:

• OAIC Notifiable Data Breaches scheme
• APRA CPS 234 Information Security
• ASD Essential Eight
• sector and contract-specific reporting requirements

For example:

• a bank or insurer may need to assess incident reporting obligations under CPS 234
• a healthcare provider may need to consider patient privacy and clinical continuity
• a government agency may need to follow public sector security and records obligations

Involve legal and compliance when the facts matter

Bring in legal or compliance early if there is:

• evidence of exfiltration
• broad personal information access
• cross-border processing
• insurer deadlines
• law enforcement involvement
• material operational impact

BCyber’s Privacy in Depth capability is designed to support privacy obligations, including Australian privacy requirements, which is especially relevant where personal information may be involved. The key point is simple: do not wait until the technical clean-up is done before asking what you may need to report.

If personal information, health data, or regulated records may have been accessed, notification obligations can arise before the full technical picture is complete.

When should I bring in outside help?

There is a point where internal effort should give way to specialist support, and it is better to recognise that early than late.

Bring in outside help if:

• the incident is moving fast
• the scope is unclear
• ransomware or destructive malware is involved
• there is a potential legal or regulatory issue
• you lack forensic capability
• you need evidence handling for insurance or litigation
• executive confidence is low and facts are fragmented

BCyber’s CyberTriage service is built for rapid incident response and early triage, while the broader CyberSuite ecosystem can support governance, behavioural analysis, scenario testing, and compliance mapping.

Build the response team with clear roles

At minimum, include:

• IT/security leadership
• executive decision-maker
• legal/compliance
• finance if money is involved
• communications/HR if staff or reputation are affected

One person should own the incident log and coordination. Fragmented ownership is one of the fastest ways to create conflicting actions.

Know when forensic or technical support is needed

Bring in specialists when you need:

• disk or memory forensics
• log correlation across multiple platforms
• chain-of-custody discipline
• root-cause analysis
• containment recommendations without evidence contamination

A good responder will say what they know, what they do not know, and what they need next.

Decide carefully about external notifications

Law enforcement, regulators, customers, suppliers, and partners may need to be notified depending on:

• incident type
• data involved
• business impact
• public safety impact
• contractual requirements

Keep communications factual and consistent. If you need help validating whether a notification threshold has been crossed, that is a compliance question, not just a technical one.

How do I recover without letting the attacker back in?

Recovery is not the moment you feel relieved; it is the moment you prove the environment is trustworthy again.

Rebuild from known-good sources

If compromise is confirmed:

• reimage infected endpoints
• restore data from known-good backups
• rotate exposed credentials
• remove persistence mechanisms
• review scheduled tasks and startup items
• verify privileged group membership
• check conditional access and app permissions

Patch the vulnerability or misconfiguration that enabled the incident. Recovery without remediation is just delay.

Validate before reopening access

Before declaring victory, confirm:

• no repeat login attempts
• no suspicious outbound traffic
• no new admin changes
• no unauthorised forwarding rules
• no anomalous service account use
• no data integrity issues
• no broken business workflows

In practice, this is where executive reporting and compliance tracking become important. A board or regulator does not just want to know that systems are “back”; they want to know why the team believes the environment is clean.

Harden the environment after the incident

Use the incident to improve controls:

• strengthen MFA
• tighten admin privileges
• improve email filtering
• restrict cloud sharing
• test backups more often
• improve phishing awareness
• review conditional access
• reduce legacy authentication paths

BCyber’s courses and knowledge base are designed to support this learning loop. With 50 courses and 574 knowledge hub entries, the aim is not just response, but post-incident uplift.

If you want to turn lessons into repeatable behaviour, the following BCyber learning areas are especially relevant:

• incident response fundamentals
• privacy and breach handling
• access control and identity hygiene
• cloud security and mailbox compromise awareness
• governance and compliance mapping

Real-world scenarios: what this looks like in practice

Financial services example

Healthcare example

Government example

Frameworks and resources worth checking

The following references are especially useful during and after a suspected compromise:

• NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide

• NIST Cybersecurity Framework 2.0

• APRA CPS 234 Information Security

• ASD Essential Eight

• ACSC ReportCyber

• OAIC Notifiable Data Breaches scheme

• ISO/IEC 27001 overview

BCyber recognition and capability context

BCyber was named a finalist in:

• 2025 Finalist Cybersecurity Professional Of The Year — Karen Stephens, Co-Founder & CEO
• 2025 GRC Provider of the Year — Finalist
• 2025 AI Innovator - Cyber Security — Finalist

These recognitions reflect the focus of our CyberSuite ecosystem:

• GRACE Portal for centralised resilience visibility
• Paradigm for AI-driven GRC automation
• Profiler for behavioural intelligence and insider-risk signals
• TopSpin for storage forecasting and capacity trend analysis
• CyberTriage for rapid incident response
• Perfect Storm for scenario modelling and war gaming
• Privacy in Depth for privacy management

Conclusion

If you think you’ve been hacked, the safest sequence is:

1. Contain first
2. Preserve evidence
3. Determine scope
4. Protect identity, finance, and operations
5. Check legal and notification obligations
6. Recover only from known-good states
7. Use the incident to strengthen controls

Do not rush into cleanup before you know what you are cleaning. Do not assume the first alert tells the whole story. And do not treat compliance as a paperwork step at the end — in Australia, it is often part of the response itself.

The strongest response is structured, documented, and honest about what is known, what is not known, and what still needs to be checked.

Key Takeaways

• Contain the incident before attempting cleanup, or you may lose evidence and let the attacker continue.
• Isolate compromised accounts, devices, and cloud services from clean systems as quickly as possible.
• Start an incident log immediately and preserve logs, screenshots, emails, and other relevant evidence.
• Check identity, email, finance, and cloud platforms early because they are common high-value targets.
• Review Australian privacy, contractual, APRA, and sector notification duties as soon as personal or regulated data may be involved.
• Use frameworks such as NIST, ISO 27001, and the Essential Eight to structure your response.

Frequently asked questions

What is the first thing I should do if I think I’ve been hacked?

Should I change all my passwords right away?

Do I need to report a suspected hack in Australia?

Can I just turn everything off to be safe?

When should I get external incident response help?

Verification and editorial note: Statistics and organisational details in this article are based on BCyber’s internal platform inventory and service information available at publication time. Readers should verify all legal, regulatory, and technical requirements against primary sources and their own advisers. This article is general information only and is not legal, financial, or professional advice. BCyber has a commercial interest in cybersecurity, GRC, incident response, and privacy-related services, which may influence the products and capabilities referenced here. This content is AI-assisted and human-reviewed.