How to write a security incident report: template, example and follow-up checklist
A good security incident report does more than describe what happened.
It should give the next person a clear account of what is known, show where the supporting evidence can be found, make uncertainty visible and identify what needs to happen next.
That sounds straightforward. In practice, incident reports can become less useful when facts, assumptions and conclusions are mixed together, important evidence is not referenced, or recommendations are recorded but never followed through.
This guide explains how to write a security incident report from the initial record through to follow-up and closure. It includes a practical template, a worked example and a checklist you can use to review your own reports.
Security incident report template: what should you record?
As a starting point, a security incident report should normally record:
-
incident or reference number;
-
name and role of the person making the report;
-
date and time the report was created;
-
date and time of the incident;
-
exact location;
-
type of incident;
-
people involved;
-
a factual description and chronology;
-
immediate impact;
-
action taken at the time;
-
people or organisations notified;
-
relevant evidence and where it is held;
-
facts or circumstances that remain unknown;
-
follow-up actions required;
-
report status and, where appropriate, version.
The precise fields will vary according to your organisation and the type of incident.
Download SIRV’s free security incident report template in Word or PDF.
The template is useful on its own or can be adapted to match your organisation’s own procedures and terminology.
1. Deal with the incident before writing the full report
The first priority during an incident is the incident itself.
That might mean protecting people, contacting the emergency services, following an evacuation or security procedure, restricting access to an area, calling a manager or preserving evidence.
Do not delay necessary action because you are trying to complete a formal report.
There are usually two stages to useful incident reporting.
The initial record
Capture the essential facts as soon as practical while events are still fresh.
This might include:
-
what has happened;
-
where it happened;
-
when it happened;
-
who is involved;
-
immediate consequences;
-
what action has already been taken;
-
who has been informed;
-
anything requiring urgent follow-up.
The initial record may be brief.
Its purpose is to make sure important information is not lost and that the people taking over the incident have enough information to act.
The fuller report
Once the immediate situation is under control, the initial record can be developed into a more complete incident report.
This is the opportunity to check timings, add relevant evidence, correct errors, record outstanding uncertainties and document subsequent actions.
Do not silently rewrite the history of the incident simply because more became known later.
Where it matters, distinguish what was known at the time from what was established afterwards.
2. Record what is known, not what you think probably happened
One of the most important disciplines in incident reporting is separating fact from assumption.
Consider this statement:
“The man tried to break into the building.”
It sounds clear, but how much of it has actually been established?
Perhaps a security officer saw someone pull a door handle several times. That is an observation.
Whether the individual intended to break in is a conclusion about motive.
A more useful report might say:
“At 22:14, I observed a male approach the east staff entrance and pull the external door handle three times. The door remained locked. I did not hear the individual speak and I do not know why he attempted to open the door.”
The second version may sound less dramatic, but it is more useful.
It tells a later reviewer what the officer actually saw and what remains unknown.
Four useful categories
When writing or reviewing a report, it can help to distinguish between four types of information.
Observed
Something the reporter directly saw, heard or experienced.
At 22:14 I saw the individual pull the staff entrance door handle three times.
Reported by somebody else
Information provided by another person.
At 22:18 the receptionist told me that the same individual had approached reception approximately ten minutes earlier.
Supported by another record
Information subsequently checked against CCTV, access control, alarm records or another source.
The access-control record shows no successful credential use at the east entrance between 22:00 and 22:20.
Unknown or assessment
Something that has not yet been established.
The reason the individual attempted to open the door is not known.
This distinction becomes particularly important when an incident is later reviewed by management, HR, insurers, police, lawyers or another investigating body.
A report should help that reviewer understand the evidence. It should not require them to work out which parts were observation and which parts were speculation.
3. Build a clear chronology
Most security incidents become easier to understand when they are set out in time order.
Use precise times where they are known.
For example:
22:14 Security officer observes an individual attempting to open the east staff entrance.
22:15 Officer approaches the entrance from inside the building.
22:16 Individual walks towards the visitor car park.
22:17 Control room informed by radio.
22:19 CCTV operator begins reviewing footage.
22:23 Duty manager informed.
22:31 CCTV review identifies the individual’s initial arrival at 22:09.
A chronology makes it easier to identify missing information and compare the report with other records.
If the time is approximate, say so.
Writing “approximately 22:15” is better than giving a precise time that cannot be supported.
4. Record the immediate impact and response
An incident report should explain what changed as a result of the event.
Depending on the incident, this could include:
-
injury or concern for someone’s welfare;
-
damage;
-
loss;
-
disruption;
-
a security control being defeated or bypassed;
-
an area being closed;
-
a contractor being stopped;
-
police or emergency-service attendance;
-
additional security measures being introduced.
Then record the actions taken.
For example:
The east entrance was checked at 22:20. No damage was identified and the door remained secure. The duty manager asked the control room to retain the relevant CCTV footage and requested an additional patrol of the east perimeter.
Avoid making the report look more complete by claiming an outcome that has not actually been checked.
For example, “the building was secure” is a broad conclusion.
It may be more accurate to state exactly what was checked:
The officer checked the east entrance, loading-bay door and adjacent ground-floor windows. No damage or open access point was identified.
Specific observations are usually more useful than reassuring conclusions.
5. Identify the evidence
The report does not need to contain every piece of evidence.
It should, however, make clear what relevant evidence exists and where an authorised reviewer can find it.
Depending on the incident, that might include:
-
CCTV or VSS footage;
-
access-control records;
-
alarm records;
-
photographs;
-
witness accounts;
-
Daily Occurrence Book entries;
-
control-room logs;
-
visitor records;
-
patrol records;
-
radio or telephone records;
-
emails or messages;
-
police reference numbers;
-
maintenance records;
-
related reports.
For example:
CCTV cameras E03 and E05 cover the east entrance and adjacent car park. Relevant footage has been identified between 22:05 and 22:25 and retained in accordance with the organisation’s procedure.
Or:
Access-control activity for the east entrance was checked for 22:00 to 22:30. No successful credential use was recorded during that period.
Do not claim that the absence of a record proves something did not happen.
A missing access-control record, for example, is missing evidence. It is not automatically proof that nobody entered.
This is also one reason why important decisions should retain the information and reasoning on which they were based. ProtectUK guidance in the context of suspicious activity recommends retaining records of issues, decisions and the reasoning behind them because these records may later be important to investigations or inquiries.
6. Worked security incident report example
The following fictional example shows how the different elements can be brought together.
Incident
Reference: SEC-2026-0812-04
Reported by: J Smith, Security Officer
Incident date: 12 August 2026
Location: East staff entrance, Building A
Incident type: Attempted unauthorised access / suspicious activity
Incident description
At approximately 22:14, while walking from reception towards the east corridor, I observed a male outside the east staff entrance.
The individual pulled the external door handle three times. The door did not open.
I approached the door from inside the building. When I was approximately five metres from the entrance, the individual walked away towards the visitor car park.
I did not speak to the individual.
I informed the control room by radio at 22:17 and asked for the CCTV covering the entrance to be reviewed.
Description
Male, estimated 30 to 40 years old, approximately 180 cm tall. Dark jacket, blue jeans and light-coloured trainers. Carrying a black backpack.
Immediate impact
No entry to the building was observed.
No damage to the east entrance was identified during an inspection at approximately 22:20.
The reason the individual attempted to open the door is not known.
Evidence
CCTV cameras E03 and E05 cover the entrance and car park.
Control room operator A Jones reviewed footage from 22:05 onwards and identified an individual matching the description entering the visitor car park at approximately 22:09.
Access-control activity for the east entrance was checked between 22:00 and 22:30. No successful credential use was recorded during this period.
Relevant CCTV footage was retained in accordance with the site’s procedure.
Notifications and actions
22:17 – Control room informed.
22:20 – East entrance physically checked.
22:23 – Duty security manager informed.
22:25 – Additional patrol requested for east perimeter and car park.
22:31 – CCTV review completed.
Outstanding questions
The identity of the individual has not been established.
The reason for attempting to open the staff entrance is unknown.
It has not yet been established whether the individual attended any other entrance.
Follow-up
Review available CCTV from other external cameras for the period 22:05 to 22:35.
Check whether reception or other staff interacted with the individual.
Duty security manager to decide whether any further reporting or escalation is required.
Include relevant information in the next security-team briefing.
This example deliberately leaves questions unanswered.
A good report does not need to make uncertainty disappear. It needs to make uncertainty visible.
7. The incident report is not the end of the process
A common weakness in incident reporting is that considerable effort goes into recording what happened, but much less attention is given to what happens next.
A recommendation such as:
“Review access arrangements.”
is not yet an action.
Who will review them?
By when?
What decision is required?
How will anybody know that the action has been completed?
A simple follow-up record might look like this:
| Action | Owner | Due date | Status | Outcome/evidence |
|---|---|---|---|---|
| Review east entrance CCTV coverage | Security Manager | 19 Aug | Open | |
| Check whether similar attempts have been recorded in previous 90 days | Control Room Manager | 15 Aug | Open | |
| Inspect door and locking arrangements | Facilities Manager | 14 Aug | Complete | No defect identified |
| Brief security team on incident | Shift Manager | 13 Aug | Complete | Recorded in team briefing |
The principle is straightforward:
incident → review → decision → action → owner → follow-up → outcome
Health and Safety Executive guidance on incident investigation similarly emphasises learning from incidents and taking action to reduce the chance of recurrence.
The same principle is useful in security.
A report creates a record. The organisation still needs to decide what the record means and what, if anything, should change.
8. Look across incidents, not just at one incident
Some incidents appear insignificant when looked at individually.
The value may emerge when records are considered together.
For example:
-
Have there been repeated attempts to access the same entrance?
-
Do incidents cluster around particular times?
-
Is one location generating disproportionate numbers of reports?
-
Are different officers recording similar suspicious behaviour?
-
Have the same recommendations been raised previously?
-
Are actions repeatedly being opened but not completed?
-
Did an earlier incident reveal a weakness that has appeared again?
This is where consistent reporting becomes particularly valuable.
If every report uses different terminology and important fields are regularly left blank, comparison is difficult.
If information is captured consistently, teams have a better chance of spotting patterns and retaining lessons rather than repeatedly starting from the latest incident.
9. Check whether the incident needs to be reported elsewhere
Your internal security incident report may not be the only report required.
Depending on what happened, your organisation may need to consider separate reporting or escalation requirements.
Examples include:
-
contacting the police or emergency services;
-
reporting certain work-related incidents under RIDDOR;
-
following safeguarding procedures;
-
notifying an insurer or client;
-
following sector-specific reporting requirements;
-
assessing whether a personal-data breach must be reported to the Information Commissioner’s Office.
Not every security incident falls into one of these categories.
For example, RIDDOR covers specified types of work-related injuries, diseases and dangerous occurrences rather than every incident that takes place at work.
Similarly, not every information-security or physical-security incident is a reportable personal-data breach. Where a personal-data breach meets the reporting threshold, current ICO guidance requires notification without undue delay and within 72 hours of becoming aware of it.
Your organisation should have procedures for deciding which additional reporting routes apply.
An internal security report should support those processes. It does not replace them.
10. Security incident report follow-up checklist
Before treating an incident record as complete, check:
-
Has the incident been given a reference number?
-
Are the date, time and location clear?
-
Is the reporter identified?
-
Is the chronology understandable?
-
Are observations distinguished from information provided by other people?
-
Have assumptions been removed or clearly identified?
-
Are important unknowns recorded?
-
Is the immediate impact clear?
-
Are the actions taken at the time recorded?
-
Are relevant photographs, CCTV, access-control records or other evidence identified?
-
Is it clear where that evidence is held?
-
Have relevant internal notifications been recorded?
-
Has somebody considered whether external reporting or escalation is necessary?
-
Have follow-up actions been identified?
-
Does each action have an owner?
-
Does each action have a target date where appropriate?
-
Is completion of the actions being checked?
-
Has the eventual outcome been recorded?
-
Have any lessons that apply elsewhere been identified?
-
Has the report been retained in accordance with the organisation’s requirements?
From incident reports to retained operational learning
Good incident reporting starts with consistent information.
But recording is only one part of the operational process.
Once an incident has been captured, organisations may still need to triage it, review the available evidence, identify patterns, make decisions, allocate actions, check that those actions are completed and retain useful lessons.
This is where structured reporting and controlled use of AI can work together.
SIRV Internal Reports provides structured incident and event reporting, including custom forms, audit records and follow-up workflows.
SIRV AI is designed to work across the subsequent operational process, helping teams connect information to review, decisions, actions, owners, follow-up and retained learning.
That does not mean asking AI to decide what happened.
An AI system should not turn an uncertain observation into a fact, establish someone’s intent, decide responsibility or replace the person accountable for reviewing the incident.
The useful role is narrower.
It can help authorised teams work through information consistently, retrieve the relevant approved procedure, identify records that may need attention, find patterns across previous reports and keep actions and learning connected.
The accountable judgement remains with the appropriate person.
Frequently asked questions
What is a security incident report?
A security incident report is a structured record of a security-related event. It normally records what happened, when and where it occurred, who was involved, the immediate response, relevant evidence and any follow-up required.
What should I write in a security incident report?
Start with the essential facts: who, what, when and where. Then record the impact, actions taken, notifications made, available evidence, important unknowns and follow-up actions.
Avoid guessing at motive or cause where this has not been established.
Should I explain why the incident happened?
Only where the reason has actually been established.
If the cause or motive is unknown, record it as unknown. An investigation or later review may establish more information.
Should a security incident report include CCTV?
You can identify relevant CCTV footage and where it is retained without necessarily copying the footage into the report itself.
The same principle can apply to access-control records, photographs, witness accounts and other supporting material.
Follow your organisation’s requirements for handling, access and retention.
What is the difference between an incident report and a Daily Occurrence Book?
A Daily Occurrence Book is normally a chronological log of activity during a shift or at a location.
An incident report provides a more detailed record of a particular event.
An incident may therefore first appear in the Daily Occurrence Book and also require a separate incident report.
When should a security incident report be completed?
Record the initial facts as soon as practical, but do not delay urgent action in order to complete paperwork.
A fuller report can be completed once the immediate situation is under control and relevant information can be checked.
Does writing the report complete the incident?
Not necessarily.
The report may identify actions, further investigation, external reporting or lessons that need to be followed through.
A useful incident-management process therefore records not only the event but also the resulting decisions, actions, owners, outcomes and learning.
Download the free security incident report template
SIRV provides a free security incident report template in Word and PDF format.
Use it as a starting point and adapt it to your organisation’s procedures, reporting requirements and operating environment.
The aim is not to create a longer report.
It is to create a clearer record: what happened, what is known, what evidence supports it, what remains uncertain and what happens next.
Contents
- What to write in a security incident report
- When to write the report
- Where to write the report
- Who should write the report
- How to write a good security incident report
- Why write a security incident report
Short on time?
If you’re short on time then use the below summary:
What to write down in security incident report: Who you are, date, time and location. Then add what happened, what’s the impact of the incident, what you’ve done as a result and who you’ve told about the incident. Later, add lessons learnt.
When to write the report: Do not make the report the priority, deal with the incident first. Then write a preliminary, summary report. In next few days, write a full detailed report.
Where to write the report: Write information wherever you can safely store it. Later, add it to a formal incident report template. The report can be written at the scene or at a desk. Make sure handwriting is legible.
Who should write the report: Often, the person who finds the incident makes a report, which may be followed-up by someone else. Speak to witnesses. Only authorised people should view the report.
How to write the report: Use facts, not fiction, avoid stories or assumptions. Write events in a time, chronological order. Be honest, even if you’re not proud of your actions.
Why write a security incident report: We can only learn from security incidents if a report is made. They can also form an important part of legal proceedings.
What is a security incident report?
A security incident report is an account of an untoward security event. For example, theft, assault and anti-social behaviour. But, they may also include non-physical incidents such as a cyber security breach. Incidents reports can be hand written or entered online using software such as our Incident and event reports feature.
Security incident report template PDF
Security incident report template Word
What to write in a security incident report
A security guard should write the following in a security incident report, it’s split onto two parts.
Part 1)
As soon as possible after the security incident record:
- Orientation: Kind of security incident, its time, date and location. For example, theft at 10:59 2 January 2024, West Wing.
- Incident description: Details about what happened, who was involved and relevant details. For example, female customer had purse stolen by the assailant, a hooded man, who ran north into the high street.
- Affected systems/resources: Was anything impacted by the security incident. For example, the assailant damaged the north emergency exit door while running away.
- Impact assessment: What were the consequences of the security incident? For example, the emergency exit door set-off an alarm and local retailers began to evacuate.
- Response actions taken: What actions were taken immediately after the incident. For example, security officer was posted to the damaged emergency exit and the customer was taken to our local canteen.
- Notification: List who has been notified about the incident. For example, the police were called about the theft and my security manager was told immediately.
- Evidence and documentation: Reference or add any relevant evidence. For example, list CCTV footage relevant to the theft.
- Your details: Add your name and contact details to the security incident report form.
Part 2)
Follow-up the security incident in next few days and write:
- Follow-up actions: List any ongoing or future actions that will be taken to address the incident. For example, security guards will now patrol the location of the theft every hour.
- Lessons learnt: Note lessons learnt and how similar incidents can be prevented in the future. For example, notices are now displayed in the area warning customers about thefts.
- Recommendations: Provide recommendations for improving security. For example, more security officers should be sent to the area
- Add details of you and any authorising parties: Add your name and contact details to the security incident report form. Add the name and contact details of anyone who has approved the report.
See proof in practice in the DLR real-time reporting case study:
Sample incident report template
[Organisation Name]
[Address]
[City, postcode]
[Phone number]
[Date of incident report]
Security Incident Report
- Incident Details:
Date and time of incident: [Date] [Time]
Location of incident: [Location]
Incident Type: [e.g., Unauthorised Access, Data Breach, Theft]
Incident Severity: [Low, Moderate, High, Critical]
- Incident description:
Provide a detailed description of the incident, including what happened, who was involved, and any relevant circumstances leading up to the incident.
- Affected systems/resources:
List all systems, equipment, or resources that were affected by the incident.
- Impact assessment:
Describe the impact of the incident, including potential data loss, system downtime, financial loss, or other consequences.
- Response actions taken:
Outline the actions taken immediately after discovering the incident, including any security measures implemented to reduce further damage.
- Notification:
Indicate whether law enforcement, regulatory authorities, or affected parties were notified, and provide details on the individuals or organisations contacted.
- Evidence and documentation:
Attach any relevant evidence, logs, or documentation that supports the incident report. Include witness statements, security camera footage, or system logs, if applicable.
- Follow-up actions:
List any ongoing or future actions that will be taken to address the incident, including security improvements, policy changes, or training initiatives.
- Lessons learned:
Discuss what lessons were learned from the incident and how similar incidents can be prevented in the future.
- Recommendations:
Provide any recommendations for improving security or preventing similar incidents in the future.
- Incident Reporting Personnel:
Name: [Your Name]
Title: [Your Title]
Contact Information: [Your Phone Number]
Email: [Your Email Address]
- Approval:
[Signature of Supervisor or Security Officer]
Name: [Supervisor/Security Officer Name]
Title: [Supervisor/Security Officer Title]
I keep six honest serving-men (they taught me all I knew). Their names are what and why and when and how and where and who.
How to remember what to write
What to write in a security incident report it simple, just remember these six prompts:
- What happened?
- Where did it happen?
- Why did it happen?
- Who was involved or witnessed the incident?
- When did it happen?
- How did it happen?
A great way to remember these six prompts is Rudyard Kipling’s poem ‘Six Honest Serving Men’.
2) When to write the report
Because memories fade it’s important to write a security incident report while it’s fresh in the mind. For this reason, often incident reports are made in two stages:
- Initial, preliminary report, written straight after the security incident
- Full report, written over next few days
By publishing the preliminary report straight after the incident you quickly make interested parties aware of it. A full report is likely to be more comprehensive than a preliminary report.
The report is not the priority
Make a report only if it is not a distraction from an ongoing incident. Prioritise the incident on site, then make an entry. For example, if there’s a protest on site, attend immediately to the incident rather than the report.
If, for whatever reason, you do not have time to complete a full entry, make an abbreviated report and complete as soon as possible. For example, if it is the end of shift and an incident occurs, you may not have time to complete a full entry. In this instance, make an abbreviated entry and complete when next on shift.
3) Where to write the security incident report
Many people write their report at the location of the incident, ‘in the field’.
In the first instance, you can record the incident using any storage device for example, an audio or video recording may be appropriate. It’s important to capture information while it’s fresh in people’s minds. If that means you need to write on a napkin and write-up the report later, that’s fine.
Most report writers will use paper or digital form enhanced by media to publish their findings.
Paper and digital reports
Paper or digital reports are used to record security incidents. But, if paper ensure a permanent ink is used to make entries. Do not use a pencil because it’s is easily erased and fades over time.
Handwriting and legibility
Many people’s handwriting is difficult to read (I know mine is). Therefore, to avoid this problem many people will use software. However, if paper is used it is important your handwriting is legible. Consider using CAPITAL LETTERS. Because capital letters slows down writing and makes each letter easier to read.
Spelling
If you use a digital report your text will be automatically checked for spelling errors. However, if you are using a paper book remember:
- A security incident report is not a writing test, do not get anxious
- If uncertain about spelling use a dictionary.
Made a mistake?
If you or someone else makes a mistake on paper do not score through or mark out the error. Make a reference to the error and then add the correction elsewhere.
Here at SIRV we use a versioning system. Therefore, no entry is ever deleted but new versions are updated. This means there is a full audit trail of changes made.
ELBOW
If you use paper, then ELBOW is a useful acronym for some basic rules.
Do not:
- Erase. Do not rub out or score through mistakes. Initial the error and make another entry.
- Leaves should not be torn out of a book. Even if the page has only one entry. Any errors should be initialed and explained.
- Blank spaces are not helpful. Because if your book has a reference coding system, any spaces will make the system hard to follow. Avoid blank spaces and use all the lines in the book.
- Overwriting is difficult to read and destroys previous entries. Do not overwrite.
- Writing between lines makes reading difficult. Do not write between lines.
4) Who should write the report?
In some organisations to write a report needs special permission (regardless of whether they attended the incident scene). If you write the report it’s important you gather information from other people involved in the incident.
This may mean talking to people at the scene and other related parties. Security incidents will often be the result of a chain of events, some of which may not be obvious at first.
Security incident report software can limit who accesses an incident report.
Who should view the reports?
Reports may include sensitive information. Therefore, it’s important access is restricted.
Cyber incidents can often be recorded by any staff member. Security guards have special software to record incident reports. For example. the daily occurrence book or incident report forms.
Often only security personnel can view reports. For example, software will use permission based access. However, viewing rights may be extended to non-security personnel.
5) How to write a good security incident report
Report writing is a skill to develop over time. A well written report is easy to follow, objective and truthful. Here’s how to become a better report writer.
Order
Write the security incident report in a chronological order and detail events in a time sequence from the past to present.
Facts not Fiction
Record the facts rather than a story or narrative. For example, imagine you’re out walking and discover an injured person lying in the street. You spot someone running away from the scene. Many people would assume the runner is the assailant (this is what we see in movies all the time). However, the runner could be someone running for help.
We are tempted to assume the runner is responsible for the person’s injuries because this is a familiar story. However, report writing is not story telling. Record the incident as you find it, don’t apply judgments. Use the same rule when taking witness statements.
No Lies
Be honest, even if you’re not proud of your actions.
6) Why write a security incident report
An incident report helps us learn from our mistakes and make the world a better place. By simply writing down the sequence of events we are creating an external account that can aid legal or civil proceedings. Incident report software such as, SIRV helps with this process.
A security report can appear daunting and time consuming but it’s a hugely valuable exercise. Everyone from manager to CEO could benefit from the report you write.
Frequently asked questions
What is a security incident report?
A written account of an untoward event, for example theft, assault or anti-social behaviour. It may also cover non-physical incidents such as a cyber breach.
What should a security incident report include?
Your details, date, time and location, a factual description, affected systems or resources, impact, immediate actions, who was notified, evidence references and follow-up actions, lessons learned and recommendations.
When should I write the report?
Deal with the incident first. Submit a brief preliminary report as soon as practical, then a full detailed report within the next few days.
Who should write the report and who can view it?
Usually the first responder writes the initial entry and a supervisor or investigator may add detail. Only authorised personnel should access the report.
How do I write a good report?
Use facts not fiction, avoid assumptions, write in chronological order and be honest. If using paper, write legibly in permanent ink and follow basic rules like avoiding overwriting.
Where should I write and store reports?
Capture details wherever safe and then use a formal template. Store securely with restricted access and version control so changes are fully auditable.
Is there a Word or PDF incident report template?
Yes. This guide provides downloads for both Word and PDF templates to adapt to your organisation.
Does this relate to Martyn’s Law?
A clear incident reporting process supports readiness and audit, which will help organisations subject to the Protect Duty meet their obligations.
"SIRV helped us move beyond basic reporting into a system that actively supports decision-making". Les O'Gorman, Director of Facilities, UCB - Pharma and Life Sciences
