Why is portfolio scale changing the incident problem?
Renewable energy operations are expanding rapidly. The International Energy Agency estimates that the world added about 800 GW of renewable capacity in 2025. Solar photovoltaic capacity accounted for more than three-quarters of those additions, while annual wind additions reached a record of about 160 GW.1 Battery storage also expanded quickly, with the IEA reporting that additions rose by about 40 per cent in 2025 to almost 110 GW.2
Those figures describe generation and storage capacity. They also imply a larger operating footprint. More assets have to be constructed, commissioned, inspected, maintained, repaired, and eventually decommissioned. The work may be undertaken by an owner, an operator, an original equipment manufacturer, an independent service provider, several contractors, or a changing combination of them. A single portfolio can contain wind turbines, solar plants, substations, battery energy storage systems, access roads, warehouses, control rooms, and temporary work areas.
Growth therefore creates an incident-management question as well as an engineering one. Can an organisation connect an asset alarm with the people who may be affected, the work under way, the contractor responsible, the communications available, and the decisions required? Can it do so across sites that use different technologies, operating partners, procedures, and reporting lines?
Technical monitoring is necessary, but the response can fail in the spaces between systems. One platform may know the condition of the asset. Another may contain the work order. A contractor supervisor may hold the current team list. A control room may know that an alarm has occurred, while an HSE leader knows what conditions would require an evacuation or a stop to work. An executive may receive a summary after several people have already translated the same event into different language.
A mature operating model connects those perspectives without pretending they are interchangeable.
What can SCADA tell an operator?
Supervisory Control and Data Acquisition, commonly shortened to SCADA, provides monitoring and control information about technical systems. For wind generation, the IEC 61400-25 series defines information models and information exchange for communication between wind power plant components and monitoring or control systems.3 The precise technical architecture varies across assets, but the boundary question remains the same.
SCADA can tell an operator that a parameter has moved outside an expected range, a component has changed state, communications with an asset have been lost, or a protective function has operated. It can preserve timestamps, measurements, alarms, and status changes that technical specialists need for diagnosis.4 That information should remain in the system designed to interpret it.
The limit appears when the event creates consequences beyond the equipment. A turbine alarm does not identify whether a technician is inside the nacelle, travelling to the site, or waiting for authorisation at an access point. A communications loss does not reveal whether the asset is unavailable, the data path has failed, or a field team is working under a separate procedure. A battery alarm does not, by itself, establish who is present, whether nearby work has stopped, which emergency service has been contacted, or who owns the next decision.
The distinction is particularly important for battery energy storage systems. UK Health and Safety Executive guidance identifies responsibilities that can apply across design, installation, and operation, including the management of electrical, fire, explosion, construction, and public risks.5 Technical alarms form part of that control environment. The wider response still has to connect competent technical judgement with people, access, isolation, emergency arrangements, neighbouring activities, and external responders.
SCADA should remain authoritative for the technical state it measures. An incident-management layer should add the operational context needed to decide what that state means for people and work.
When does an asset alarm become a people incident?
Not every alarm should activate a formal incident structure. Operators need thresholds that reflect consequence rather than noise. A recoverable equipment fault with no exposure beyond normal operations may stay within routine maintenance. The same technical fault may require a broader response when it affects occupied equipment, removes a critical control, creates uncertainty about field personnel, interrupts the only communications route, threatens surrounding infrastructure, or requires coordination across several organisations.
The activation decision should answer four questions. What has changed? Who or what may be affected? Which normal control has become insufficient? Who has authority to set objectives and coordinate the response?
These questions prevent two common errors. The first is treating every technical alert as an organisational emergency. That overwhelms people and weakens confidence in escalation. The second is leaving a developing people problem inside a technical workflow because the initiating event was an equipment alarm. That can produce excellent diagnosis without clear accountability for welfare, communications, access, or wider operational consequence.
The threshold also needs to account for uncertainty. A loss of contact with a lone engineer may have an ordinary explanation. It may also remove the evidence needed to confirm that work remains safe. HSE guidance states that employers must manage the risks of lone working, including for contracted and self-employed people, and notes the additional difficulty created when someone has no close or direct supervision.6 A non-response should therefore initiate the organisation's agreed verification and escalation procedure. It should not be treated as proof that the person is safe or in danger.
A good activation model makes these distinctions visible. It records why the incident was opened, which assumptions remain unverified, what would justify escalation, and what conditions would support a return to routine management.
Who belongs in the affected population?
The affected population is wider than the employee directory. It may include direct employees, contractors, subcontractors, visiting specialists, drivers, temporary workers, and people whose work is controlled by another organisation. Their presence may be recorded in access systems, permits, work orders, travel bookings, contractor records, or local sign-in arrangements.
No single source should be assumed complete. A work order can name the planned technician but not a replacement sent that morning. A site-access record can show entry without explaining the task or supervisor. A vehicle record can identify the driver without confirming every passenger. A location point can show where a device was last reported without confirming who holds it or whether that person is safe.
The response team should establish the initial affected population from the best available evidence, record the source and time of each item, and keep the population under review. People should be added or removed for a stated reason. A confirmed response should record what has actually been confirmed. “Safe”, “left site”, “needs assistance”, and “no response” are different states and should not be collapsed into a general contact count.
This discipline also helps with false reassurance. A message marked as sent does not prove receipt. A delivery receipt does not prove understanding. A reply from a supervisor may confirm a team's status, but it should remain distinguishable from direct replies if that difference matters to the organisation's procedure. The purpose is not to reject useful evidence. It is to preserve enough context for leaders to understand its strength.
How should contractor information enter the response?
When specialist contractors work across renewable construction and operations, their expertise does not remove the need for coordination. HSE guidance for shared workplaces says employers need to cooperate, coordinate their measures, and exchange information about risks that may affect each other's workers.7 Separate HSE human-factors guidance identifies coordination between clients, contractors, and subcontractors, induction, supervision, competence, and the assessment of hazards introduced by contracted work as core considerations.8
Incident arrangements should make those relationships operational before an event. The asset owner or operator needs to know which organisation controls the work, who can confirm personnel status, who can stop the task, who can provide technical information, and who will communicate with families, regulators, emergency services, or clients where required. The contractor needs to know how to raise an alarm, how the site response will be led, and which information it must supply.
This does not require every organisation to surrender its own management structure. ISO 22320 applies to incidents involving one organisation or several organisations that continue to use their own structures. Its incident-management components include roles, responsibilities, tasks, resources, joint direction, and cooperation.9 The practical requirement is a shared account of the event and explicit ownership at the points where responsibilities meet.
The incident record should therefore preserve organisational affiliation as well as a person's name or role. It should identify whether an action belongs to the operator, a service provider, a site contractor, or an external responder. Where one action depends on another organisation, the dependency should be visible. A deadline without a clear accepting owner is not yet an accountable action.
What should happen when connectivity becomes unreliable?
An incident plan should allow for the possibility that normal communications become unavailable at a site or along the journey to it. The design question is how the response continues when the primary bearer is lost.
The communications plan should identify the primary route and the alternatives appropriate to each site or journey. It should define who monitors them, when a team changes route, how contact attempts are recorded, and how information gathered by voice, radio, or an offline process enters the main incident record. Devices, subscriptions, charging, antenna position, user training, and test routines all matter. A satellite device that is unavailable, uncharged, incorrectly configured, or unfamiliar to its user is not a resilient arrangement.
International Telecommunication Union guidance describes satellite systems as capable of supporting fixed and mobile communications and of operating alongside other communications solutions. It also notes the role of portable satellite phones and terminals in emergency response.10 The lesson for a commercial operator is not that satellite should replace mobile service. It is that communications resilience should match exposure.
The AtlasNXT mobile app is the normal route for app-based alerts, Check-Ins, Panic, Overwatch, and configured location capabilities where smartphone connectivity is suitable. Approved compatible satellite devices can support workers and journeys where the operating environment and communications plan require them, subject to the selected hardware, airtime, configuration, and service availability. Organisations should define the transition between methods. They should not assume that one will automatically replace another.
ReachScore™ can help expose communications-readiness gaps across the people and circumstances in scope. It does not guarantee delivery or prove that a person is safe. Its value lies in helping teams ask a more precise question about whether their planned communications are appropriate for the current exposure.
Can location support safety without becoming surveillance?
During lone work, travel, site evacuation, or a developing incident, location may answer a specific operational question. That does not justify collecting more than the stated purpose requires, leaving access undefined, or making routine monitoring the default answer to every risk.
European Commission guidance on the General Data Protection Regulation describes purpose limitation, data minimisation, storage limitation, accuracy, integrity, confidentiality, and accountability as core principles. It says organisations should collect personal data for a specified purpose, limit it to what is necessary, retain it only as long as required, and restrict access appropriately.11 Other jurisdictions have their own legal requirements, which need local assessment.
An operational location policy should begin with purpose. Continuous location may be justified for a defined safety-critical activity, while consent-based or event-led location may be more appropriate elsewhere. The policy should explain who can see the information, when visibility begins and ends, how long records are retained, what happens outside working time, and how workers can raise concerns. Contractors need the same clarity, even where the legal relationship differs.
The incident interface should also avoid overstating what location proves. A current point can help establish proximity to an affected area. It does not confirm physical condition, identity, awareness, or intent. The response should combine location with Check-Ins, direct communication, supervisor confirmation, access information, and local observation as appropriate.
A proportionate design uses the least intrusive method that meets the operational need and makes the safety purpose understandable to the people affected.
What evidence should the incident record preserve?
An incident record should help the current team act and allow a later reviewer to reconstruct the response accurately. It needs more than a stream of messages. Each significant update should have a source and time. Assessments should remain distinguishable from observations. Decisions should record the information, uncertainty, and authority that shaped them. Tasks should have an owner, expected time, status, and a clear reason when they are changed, cancelled, or transferred.
This matters during handover. The incoming team should not have to infer the operating picture from a chat history or a folder of unrelated files. It should be able to see the current objectives, affected people and assets, material decisions, unresolved questions, dependencies, and next review point. The record should also show which technical system remains authoritative for specialist data.
HSE emergency guidance says people respond more reliably when plans, actions, and responsibilities are clearly agreed, recorded, rehearsed, and supported by realistic practice. It also recommends coordination where employers share a workplace.12 HSE's broader management guidance uses the Plan, Do, Check, Act approach and treats learning from incidents and near misses as an input to the next cycle of risk management.13
Closure should therefore be explicit. The immediate alarm may have cleared while welfare actions, equipment isolation, contractor communications, environmental monitoring, or follow-up decisions remain open. Closing the incident should confirm the final status of affected people, the disposition of tasks, the authority for returning work or equipment to service, and any residual uncertainty. Corrective actions should move into the organisation's normal governance with named ownership and review dates.
Where can AtlasNXT fit?
AtlasNXT can provide the people-centred coordination layer around renewable incidents. It is not a replacement for SCADA, a maintenance-management system, a battery-management system, a marine-coordination platform, or another specialist operational tool.
Remits can align geographic responsibility and authorised visibility with regions, sites, and teams. The Incident Room can keep significant updates, tasks, communications, decisions, and status changes with the event. Check-Ins can record responses and non-responses. The mobile app can support alerts, Check-Ins, Panic, Overwatch, and configured location capabilities. Live, event-led, or consent-based location can be used where appropriate. Compatible satellite devices can extend the operating model beyond suitable smartphone connectivity, subject to the selected device and service arrangement.
Where permissions, format, security requirements, and an approved integration or import permit it, relevant external data can contribute to the operating picture. The aim is controlled use of information, not indiscriminate replication of every technical feed.
This structure helps an asset manager see the human consequence of an operational event without replacing the technical diagnosis. It helps an HSE leader see contact status and unresolved cases. It helps a control room connect an alarm to the people and work it affects. It helps an incident lead maintain decisions and tasks across organisational boundaries. It gives an incoming shift a maintained record rather than a verbal reconstruction.
How should leaders test the operating model?
A useful exercise begins with an ordinary operational signal and allows the consequences to develop. A turbine stops communicating while a technician is expected on site. A BESS warning occurs during contracted maintenance. Severe weather alters access to several assets. A field team loses its primary communications route. The scenario should not begin with every fact already verified.
The exercise should test whether the control room recognises when a technical event needs people-centred coordination. It should require the team to establish the affected population, contact staff and contractors, move to an alternative communications route, assign tasks, record decisions, and provide a concise leadership update. A shift change should occur before resolution. One piece of information should conflict with another so that the team has to record and resolve uncertainty.
Leaders should judge the result by evidence. How long did it take to name an incident lead? Could the team distinguish technical status from human status? Did every material task have an accepting owner? Were contractor responsibilities clear? Could leaders see non-responses and communications gaps without interpreting them as conclusions? Did the handover preserve decisions, dependencies, and the next review point? Could the final record support a serious review?
The most revealing finding may be outside the software. The exercise may expose an outdated call tree, an untested satellite device, a missing contractor roster, an unclear activation threshold, or a privacy policy that does not match practice. Those are useful results. Incident readiness improves when the organisation fixes the connections between systems, people, and authority before the next alarm arrives.
If you want to examine how AtlasNXT could support people-centred incident management across your renewable assets, book a free AtlasNXT demonstration.
References
1. International Energy Agency, Global Energy Review 2026: Technology, Solar PV and Wind. https://www.iea.org/reports/global-energy-review-2026/technology-solar-pv-and-wind
2. International Energy Agency, Global Energy Review 2026: Key Findings. https://www.iea.org/reports/global-energy-review-2026/key-findings
3. International Electrotechnical Commission, IEC 61400-25-1:2017, Wind energy generation systems, Communications for monitoring and control of wind power plants. https://webstore.iec.ch/en/publication/29062
4. International Electrotechnical Commission, IEC 61400-25-2:2015, Wind turbines, Communications for monitoring and control of wind power plants, Information models. https://webstore.iec.ch/en/publication/22813
5. Health and Safety Executive, Grid-scale battery energy storage systems. https://www.hse.gov.uk/electricity/battery-energy-storage-systems.htm
6. Health and Safety Executive, Lone working: Protect those working alone. https://www.hse.gov.uk/lone-working/employer/index.htm
7. Health and Safety Executive, Shared workplaces. https://www.hse.gov.uk/workplace-health/shared-workplaces.htm
8. Health and Safety Executive, Human factors: Contractors. https://www.hse.gov.uk/humanfactors/topics/contractors.htm
9. International Organization for Standardization, ISO 22320:2018, Security and resilience, Emergency management, Guidelines for incident management. https://www.iso.org/standard/67851.html
10. International Telecommunication Union, Guidelines for National Emergency Telecommunication Plans. https://www.itu.int/en/ITU-D/Emergency-Telecommunications/Documents/2024/Guideline%20on%20National%20Emergency%20Telecommunication%20Plans.pdf
11. European Commission, Principles of the GDPR. https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en
12. Health and Safety Executive, Emergency procedures. https://www.hse.gov.uk/workplace-health/emergency-procedures.htm
13. Health and Safety Executive, Introduction to managing health and safety. https://www.hse.gov.uk/managing/introduction/how-to-manage.htm
