How to Evaluate Mining Software Vendor Security

Last week, dozens of Australian mining companies lost access to their key technology systems. The cause was not a mine-site incident, equipment failure, or a weather event. It was a ransomware attack on Scope Systems, a major software reseller and deployment specialist that hosts cloud-based operations for mining companies across Western Australia.

Among those affected: Northern Star Resources and Evolution Mining, Australia's two biggest gold miners. Their cloud-based operations, including hosted Pronto ERP systems, went offline. The attackers demanded a ransom. The companies scrambled.

This is not a story about Scope Systems. It is a story about what happens when mining companies treat software vendor security as someone else's problem. It is not. Your vendor's security is your security. When their systems go down, your payroll, procurement, maintenance scheduling, and operational reporting go down with them.

Most mining software buyers have never asked their vendors a single security question. This article fixes that.

Scope Systems is a Perth-based software reseller and deployment specialist. They host cloud-based versions of Pronto ERP and other operational systems for mining companies across Australia. When their infrastructure was breached, the impact cascaded downstream to every customer using their hosted services.

The Australian Financial Review reported on May 8, 2026 that "dozens of Australian mining companies are scrambling to access their key technology systems." Northern Star and Evolution Mining, with a combined market cap in the tens of billions, were among those thought to be targeted.

This is what supply-chain risk looks like in mining IT. You do not need to be breached directly. If your vendor is breached, you are breached. Your data, your operations, your downtime: all exposed because of a security failure one layer up.

The mining industry is a prime target for cyber attackers. High-value operations, heavy reliance on uptime, complex IT environments that blend legacy systems with modern cloud services. The Australian Cyber Security Centre has consistently highlighted ransomware and supply-chain attacks as growing threats for critical industries, including mining.

The Scope Systems incident is a wake-up call. But wake-up calls are only useful if you act on them.

Mining software security is not the same as corporate IT security. Three factors make it distinct.

First, your data lives on their infrastructure. Most modern mining software is cloud-hosted or hybrid. Your geological models, your mine plans, your production data, your financials: they do not sit on servers you control. They sit on servers your vendor controls. When that vendor gets breached, your data is part of the breach.

Second, legacy vendors often run outdated security practices. Many mining software tools were built decades ago for on-premise Windows environments. Their codebases predate modern security standards. Their update cycles are slow. Their cloud migrations are recent and sometimes shallow. A vendor that moved a Windows-only application to the cloud without rearchitecting for security is not a secure vendor. It is a legacy vendor with a cloud login page.

Third, mining operations are high-value ransomware targets. Downtime in mining is measured in millions of dollars per day. Attackers know this. A ransomware demand of $500,000 looks cheap when the alternative is shutting down a processing plant for 48 hours. Mining companies pay. That makes them targets.

The combination of these three factors means that evaluating vendor security is not a box-ticking exercise. It is a core part of procurement due diligence.

These six questions are designed for mining software buyers who are not security experts. They are practical, specific, and hard to evade. A vendor with solid security practices will answer them confidently. A vendor without them will dodge, deflect, or bluff.

1. Where does our data live?

This is not a trick question. You need to know:

• What cloud provider hosts the data? (AWS, Azure, Google Cloud, or a smaller provider?)
• What region is it stored in? (Australian data residency matters for compliance.)
• Is it backed up? How often? Where are the backups stored?
• Can we get our data out if we need to leave?

A good answer: "Your data is stored in AWS Sydney, with daily encrypted backups to AWS Melbourne. You can export your full dataset at any time via our API or a one-time download."

A bad answer: "We use cloud hosting." That is not an answer. That is a deflection.

2. Who has access to our data?

You are not just trusting the vendor. You are trusting everyone the vendor trusts.

• Which of the vendor's staff can access our data?
• Do they use subcontractors or offshore teams?
• What access controls are in place? (Role-based? Multi-factor authentication?)
• Are access logs reviewed regularly?

A good answer: "Only senior engineers with security clearance can access production data, and only with multi-factor authentication and manager approval. All access is logged and audited monthly."

A bad answer: "Our team is trustworthy." Trust is not a security control.

3. What happens when you get breached?

Every vendor will say they take security seriously. The ones who actually do have a plan for when it fails.

• Do you have an incident response plan? Can we see it?
• How quickly will you notify us if our data is affected? (24 hours? 72 hours?)
• Who is responsible for communicating with us during an incident?
• What is your liability if our data is exposed?

A good answer: "We have a documented incident response plan tested quarterly. We notify affected customers within 24 hours. Our liability is capped at annual contract value, and we carry cyber insurance."

A bad answer: "We have never been breached." That is not a plan. That is hope.

4. How do you prove your security?

Claims are cheap. Evidence matters.

• Do you have a current SOC 2 Type II report?
• Are you ISO 27001 certified?
• When was your last penetration test? Who conducted it? Can we see the summary?
• Do you have cyber insurance? What is the coverage limit?

A good answer: "We are SOC 2 Type II certified (report available under NDA), ISO 27001 certified, and we conduct annual penetration tests by an independent firm. Our cyber insurance covers $10 million in damages."

A bad answer: "We are working on certification." That means they do not have it. Working on it is not the same as having it.

5. Can we audit you?

You do not need to audit them yourself. But you need to know you can if you want to.

• Will you complete a security questionnaire?
• Can we review your SOC 2 report under NDA?
• Can we speak to a current customer about their security experience?
• Do you allow third-party security assessments?

A good answer: "Yes. We provide our SOC 2 report under NDA, complete security questionnaires, and can arrange reference calls with customers who have done their own assessments."

A bad answer: "Our security is proprietary." Security through obscurity is not security.

6. What is your disaster recovery plan?

If the worst happens, how quickly can they get you back online?

• What is your Recovery Time Objective (RTO)? (How long until systems are back?)
• What is your Recovery Point Objective (RPO)? (How much data can you lose?)
• When did you last test your disaster recovery plan?
• Do you have a failover site or multi-region redundancy?

A good answer: "Our RTO is 4 hours, RPO is 1 hour. We have active-active multi-region redundancy and test failover quarterly."

A bad answer: "We have backups." Backups are not disaster recovery. Backups that have never been tested are hope dressed as preparation.

Some answers are not just weak. They are disqualifying. If a vendor gives you any of these responses, walk away.

"We use AWS so we are secure." No. AWS secures the infrastructure. Your application on AWS is your responsibility. The shared responsibility model means AWS secures the cloud. You secure what you put in it. A vendor who does not understand this does not understand cloud security.

"Our security is proprietary." This is not a thing. Real security is verifiable. If they cannot explain their controls, they do not have controls.

"We have never been breached." This is not evidence of security. It is evidence of luck or obscurity. Every vendor will eventually face an incident. The question is whether they are prepared.

"Security is the IT department's job." In 2026, security is everyone's job. If the vendor's sales team cannot answer basic security questions, their engineering team probably cannot either.

"We will get certified next year." Next year is not now. Certification is not everything, but the absence of any third-party validation is a signal. They have not prioritised it. Why should you prioritise them?

No customer references willing to discuss security. If every reference deflects security questions or the vendor refuses to provide any, that is a signal. Good vendors have customers who will vouch for them.

Maybe you are reading this and realising your current vendor would struggle to answer these questions. That is common. Most mining software relationships were formed before security was a procurement priority.

Do not panic. Most security gaps are fixable. Here is what to do.

Start with a security questionnaire. Send your vendor the six questions above. Give them two weeks to respond in writing. A vendor who takes security seriously will not resent this. They will expect it.

Escalate if answers are inadequate. If the sales team cannot answer, ask to speak to their head of engineering or CISO. If they do not have a CISO, that is itself an answer.

Document everything. If you decide to stay with a vendor despite security gaps, document the gaps and the business justification. This protects you if something goes wrong later.

Know when to switch. If a vendor cannot answer basic security questions and shows no willingness to improve, the cost of switching is lower than the cost of a breach. This is not an easy decision. But it is easier than explaining to your board why you stayed with a vendor who could not prove they could protect your data.

---

This article is general guidance, not legal or security advice. Consult your IT security team and legal counsel before making procurement decisions.

• Drill & Blast Software - Software for drill pattern design, blast optimisation, and fragmentation analysis.
• Mine Planning & Design Software - Strategic and tactical mine planning, pit optimisation, and scheduling tools.
• Fleet Management & Dispatch Software - Real-time fleet tracking, haulage optimisation, and equipment utilisation.