A security and data checklist for mining maintenance software

A security review is most useful when it is tied to the exact maintenance workflow, data types, users, devices and providers proposed for a pilot. A generic assurance statement cannot show how one product configuration handles field evidence or separates customer organisations.

This vendor-neutral checklist helps maintenance, cyber, architecture, privacy and procurement teams define the evidence they need. It is an evaluation aid, not legal advice or a substitute for the customer's security process.

1. Draw the data flow first

List every place the workflow collects, transmits, stores, processes, exports or deletes information. Include user identity, asset and fault records, photos, notes, uploaded documentation, generated guidance, telemetry, logs, support systems and backups.

Name the product component and provider at each step. This makes later answers about data location, encryption, retention and subprocessors testable.

2. Define identity and access roles

Review sign-in, multi-factor authentication, account lifecycle, role assignment, privileged administration and emergency access. Map the actions available to maintainers, supervisors, reliability users, customer administrators and vendor support.

Ask how access changes take effect across active sessions, cached data, exports and queued low-connectivity work.

3. Test organisation and site boundaries

Require evidence that one customer cannot read or change another customer's assets, jobs, documents, messages or diagnostic history. Test direct identifiers, search, exports, attachments, background jobs and support tools, not only the main user interface.

If sites or business units have additional separation rules, include those in the proposed access model rather than assuming organisation membership is sufficient.

4. Review field-device and low-connectivity controls

Identify what information is stored locally, how it is protected, when it expires and what happens after sign-out, role removal or device loss. Check screenshots, downloads, attachment caches and the operating-system controls required by the supported configuration.

Use the low-connectivity field test to verify queue, replay, conflict and honest degraded-state behaviour on the intended device.

5. Inspect provider and AI processing

For each cloud, email, analytics, support, AI or document-processing provider, record the purpose, data categories, location, retention, access and contractual boundary. Confirm whether customer inputs or outputs are used for model or product training.

Distinguish the provider's general controls from the application's own configuration and data flow. Both need evidence.

6. Confirm encryption and key responsibility

Ask for the protocols and configurations used in transit, the storage services covered at rest, key ownership and any exceptions. Include backups, exported files, local device data, logs and attachments rather than reviewing only the primary database.

The response should identify evidence and scope. “Industry standard encryption” is not enough for a diligence decision.

7. Align retention, deletion and legal material

Map retention and deletion by data type, customer status and storage layer. Check production records, uploaded documents, support copies, logs, analytics, backups and provider-held data. Confirm the export window and the evidence produced when deletion is requested.

Customer agreements, privacy material and technical behaviour should describe the same boundary. Any difference needs to be resolved before the pilot uses real operating information.

8. Review logging, monitoring and incident evidence

Identify which authentication, access, administrative, data-change, export and integration events are recorded. Define who can review them, how sensitive values are protected and how long the evidence remains available.

Ask for the incident response path, customer notification boundary, support contacts and the records retained for investigation.

9. Test recovery and operational dependency

Review backup scope, restore testing, recovery objectives, provider dependencies and the user-visible degraded state. Confirm what the site can export and what process applies if the pilot pauses or the service is unavailable.

Do not treat a CSV, PDF or selected export as a complete platform backup unless the contract and technical evidence genuinely support that statement.

10. Put the evidence inside the pilot decision

Record each control as confirmed, partially confirmed, not applicable or still requiring evidence. Assign an owner, due date and acceptance decision. Test the configuration that will actually be used rather than a broader roadmap claim.

A bounded pilot can use synthetic information until the required security, privacy and contractual evidence is accepted for customer data.

Security review evidence pack

• Current architecture and end-to-end data-flow diagram
• Identity, role and privileged-access matrix
• Organisation-isolation design and test evidence
• Provider and subprocessor register
• Data-location, encryption, retention and deletion evidence
• Field-device and low-connectivity boundary
• Logging, monitoring and incident-response material
• Backup, recovery, export and pilot-exit plan
• Open risks, owners, expiry dates and acceptance record

Use the broader mining maintenance software buyer guide, then follow FaultPilot's security and procurement pathway for scope-controlled diligence material.