Securing Third-Party Access During Incident Response

When a cyberattack is unfolding, outside specialists can provide the expertise and capacity an internal team lacks. A forensic investigator may need access to endpoint telemetry, a managed security provider may need to isolate systems, and a cloud partner may be responsible for restoring a critical workload. Each additional connection, however, creates another path that attackers could exploit.

Third-party access during an incident needs to be fast enough to support containment without becoming an uncontrolled extension of the breach. Shared accounts, permanent VPN access and informal approvals can leave organisations unable to determine who changed a firewall rule, exported sensitive data or disabled a security control.

Australian organisations face a particularly complex operating environment. Incident teams may coordinate across Sydney, Melbourne, Brisbane and Perth, while international vendors work in different time zones. An external responder might join during an overnight shift or an Australian “arvo”, making clear access rules more reliable than ad hoc phone calls.

CARM Security supports a coordinated approach by bringing security technologies, response capabilities and remediation activities together. Its role in a broader incident response programme is to help organisations identify threats, contain damage and restore control while third parties work within defined boundaries.

Access model Response speed Main exposure Suitable use
Pre-approved privileged access Very fast Standing privileges may be abused High-priority providers with strong controls
Just-in-time access Fast Requires reliable approval and identity systems Most containment and investigation tasks
Supervised remote session Moderate Activity depends on active oversight Sensitive systems and high-risk actions
Screen sharing without system access Limited Evidence may be incomplete Initial assessment and coordination
Vendor-managed access Variable Visibility can be unclear Platforms where the provider owns operations

Establishing Trust Before An Incident

Third-party incident access should be designed before an emergency. Procurement and security teams need a current record of each provider, the services they support, the information they can reach and the circumstances in which they may be activated. This record should include incident response firms, cloud providers, software vendors, telecommunications companies and managed service providers.

Contracts should define more than confidentiality obligations. They should cover identity verification, privileged access management, logging, evidence handling, breach notification, subcontractor use and the return or destruction of information. Australian organisations should align these arrangements with their regulatory duties, including the Privacy Act and the Notifiable Data Breaches scheme where personal information is involved.

The provider’s people also need individual identities. A shared “vendor-admin” account makes investigation difficult and weakens accountability. Named accounts, phishing-resistant multifactor authentication and role-based permissions provide a stronger foundation. Where possible, the organisation should verify responders through an agreed channel, such as a known contact number, rather than relying on an email received during a suspected compromise.

Access should be tested during tabletop exercises. A Sydney-based business may discover that its external responder can access Microsoft 365 but not its backup console, or that an offshore provider cannot reach a system because conditional access policies block Australian locations. Finding these gaps during a rehearsal is considerably safer than discovering them while ransomware is spreading.

Applying Least Privilege Under Pressure

The principle of least privilege remains important during a crisis, but it must be applied in a practical way. A malware analyst may need read access to endpoint and identity logs. A containment specialist may need permission to isolate devices, revoke sessions or block indicators. A recovery partner may require access to backup infrastructure, but not to unrelated production databases.

Just-in-time access is usually preferable to permanent administrator rights. The organisation can approve a specific person, purpose, system and time window, then revoke the privilege automatically. A request should identify the action required, the incident commander who authorised it and the evidence that will be generated. Emergency access may be granted quickly, but it should still be recorded and reviewed later.

High-risk actions deserve an additional control. Deleting accounts, changing identity federation, modifying backup retention or wiping compromised systems can affect the investigation and the organisation’s ability to recover. These actions should require dual approval or a supervised session, particularly when a third party is acting on a production environment.

Useful safeguards include:

Access should be narrowed as the incident changes. A provider that needs broad visibility during scoping may only need access to a small set of hosts during remediation. Closing unnecessary paths is part of containment, even when those paths belong to trusted partners.

Coordinating Providers Through One Response Model

A major incident can involve several external parties at once. A cyber insurer may appoint a breach coach, an incident response firm may lead forensics, a cloud provider may support recovery, and a managed security service may monitor activity. Without clear coordination, vendors can duplicate work, issue conflicting instructions or make changes that destroy useful evidence.

The internal incident commander should maintain a third-party access register throughout the event. It should show who has been granted access, what they can reach, which actions they are authorised to perform and when their access expires. A simple register is valuable in Australia, where an organisation may need to coordinate local staff with providers in Singapore, the United States or Europe.

Communication channels should be agreed in advance. Email may be unavailable or untrustworthy during an account takeover, so the response plan should include an out-of-band channel and a process for verifying participants. The team should also define who can approve emergency changes when the usual system owner is unavailable.

Australian businesses that rely on outsourced IT support should pay close attention to concentration risk. A single managed service provider may hold administrative rights across many customers, making it an attractive target. Contracts and technical controls should prevent a compromise at the provider from automatically becoming a compromise of every connected client.

The operating model should distinguish between advice and action. A forensic consultant may recommend disabling an identity provider, while an authorised internal owner executes the change. In other cases, an external responder may act directly under pre-approved authority. This distinction prevents uncertainty about responsibility when decisions must be made quickly.

Monitoring External Activity And Evidence

Third-party actions need the same level of monitoring as internal privileged activity. Centralised identity logs, endpoint telemetry, firewall records, cloud audit trails and privileged access management data should be available to the response team. Logs should use consistent time settings so that an action performed in Perth can be correlated with an alert generated in Melbourne or an authentication from overseas.

Monitoring should look for unusual behaviour by the provider as well as by the suspected attacker. Warning signs include access outside the approved window, connections from an unexpected country, bulk downloads, privilege escalation and attempts to disable security tools. A trusted vendor account can be just as valuable to an intruder as a compromised employee account.

Evidence preservation needs explicit ownership. The organisation should decide who collects logs, who stores forensic images, how hashes are recorded and which provider may access the material. If legal proceedings, insurance claims or regulatory reporting become relevant, a defensible chain of custody can be as important as the technical findings.

A provider should not be allowed to overwrite or delete evidence simply because it is trying to restore service. Recovery and investigation may need to run as separate workstreams. Snapshots, system images and exported logs should be preserved before major changes are made, subject to the incident commander’s direction and the organisation’s legal advice.

The Essential Eight provides a useful Australian baseline for controls such as multifactor authentication, application control, patching and restricted administrative privileges. It does not replace an incident-specific plan, but it helps organisations evaluate whether their suppliers can support the same security expectations. For regulated entities, APRA requirements and CPS 230 operational risk obligations may also influence how critical service providers are assessed and supervised.

Removing Access And Learning From The Event

Third-party permissions should expire when the task ends, not when people remember to remove them. The incident commander or access owner should confirm that accounts, API keys, VPN profiles, remote management agents and temporary firewall rules have been disabled. The review should include subcontractors and support accounts that may not appear in the main identity directory.

After the immediate response, the organisation should compare approved activity with actual activity. This review can reveal whether a provider accessed systems outside its scope, whether an emergency privilege was left active or whether logging failed at a critical point. Findings should be assigned to owners and tracked through remediation rather than filed away as an incident report.

A practical close-out review should cover:

Lessons should feed into the next exercise and the next procurement cycle. If a responder could not reach essential telemetry, the organisation may need a better secure access method. If access was too broad, role definitions and approval workflows need revision. If a vendor could not provide reliable logs, that weakness should affect its risk rating and service requirements.

Third-party access is also part of stakeholder communication. Boards, customers, insurers and regulators may need a clear account of which suppliers were involved, what information they handled and what controls were applied. Keeping accurate records during the incident makes those explanations more credible and reduces the chance of contradictory statements.

The strongest arrangements combine trusted suppliers with strong technical boundaries. Trust helps teams move quickly, but it should never replace verification, least privilege, monitoring and expiry. During a breach, every external connection should have a clear owner, a defined purpose and a reliable record of what happened.

When the response is over, the essential point remains simple: third parties should be able to act quickly without gaining more access than the incident requires.