SIST-TS CEN/TS 18053-2:2024

SLOVENSKI STANDARD
01-november-2024
Digitalna skrbniška veriga za dokaze CBRNE - 2. del: Upravljanje podatkov in
presoja
Digital Chain of Custody for CBRNE Evidence - Part 2: Data Management and Audit
Digitale Beweiskette für CBRNE-Beweise - Teil 2: Datenmanagement und Audit
Ta slovenski standard je istoveten z: CEN/TS 18053-2:2024
ICS:
13.300 Varstvo pred nevarnimi Protection against dangerous
izdelki goods
35.240.99 Uporabniške rešitve IT na IT applications in other fields
drugih področjih
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 18053-2
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
September 2024
TECHNISCHE SPEZIFIKATION
ICS 13.300; 35.240.99
English Version
Digital Chain of Custody for CBRNE Evidence - Part 2: Data
Management and Audit
Digitale Beweiskette für CBRNE-Beweise - Teil 2:
Datenmanagement und Audit
This Technical Specification (CEN/TS) was approved by CEN on 26 May 2024 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 18053-2:2024 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative References . 5
3 Terms and Definitions. 5
4 Symbols and Abbreviated Terms . 5
5 Data Governance in the Digital Custody Transfer Domain . 6
5.1 General. 6
5.2 The Data Governance Process . 7
5.3 The Custody Transfer Lifecycle . 8
5.4 CTP Lifecycle . 11
5.4.1 CTP Status Management . 11
5.4.2 CTP Global Process . 13
5.5 Authentication and verification of assigned resources . 15
5.6 Managing Resources Assigned to the Mission . 17
6 Digital Custody Metadata Structure . 18
6.1 General. 18
6.2 The Relevance of Data Governance . 18
6.3 Controlling and Monitoring each Custody Transfer Point . 18
6.4 Risk Compliance and Reporting Policies . 20
7 Defining Indicators to Monitor Digital Evidence Custody . 21
8 Digital Custody Data Model . 22
Annex A (informative) Example of the dCoC domain diagram for CTP evidence . 24
Annex B (informative) Role-Permission Matrix . 25
Annex C (informative) Guidance for the Structure of the KPI Metadata . 26
Annex D (informative) Mockup of the interface for assigning Resources . 30
Bibliography . 32

European foreword
This document (CEN/TS 18053-2:2024) has been prepared by Technical Committee CEN/TC 391
“Societal and citizen security”, the secretariat of which is held by AFNOR.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Introduction
This document presents the metadata that should be considered for automating the custody transfer of
digital evidence items within a digital Chain of Custody (dCoC). The goal is to provide guidelines for a
standardized metadata structure for auditing the custody transfer between stakeholders. These
guidelines intend to support data integrity and to ensure compliance with business rules in each custody
transfer point (CTP).
The proposed data structure is designated as Digital Custody Metadata (DCM). It is an essential tool for
auditing the data governance workflow, providing a digital log with information about who has custody
and how that custody was transferred between stakeholders. Such information should be admissible in
administrative, disciplinary, and judicial proceedings. If a digital log of each custody transfer is not
preserved, the evidence presented in court may be challenged and ruled inadmissible. Therefore, the goal
is to provide guidelines for a non-repudiation digital log, ensuring a standard data structure for data
management and auditing.
In order to understand who holds a CBRNE digital evidence item within each CTP lifecycle, the DCM
should provide comprehensive information. This information encompasses details about the location and
timing of the custody transfer, identification of the custody owner and receiver, and metadata about the
package used for transporting the digital evidence items. Additionally, the DCM should provide insights
into the status of the CTP, including information about successfully executed CTPs and triggers for
situational awareness.
In this domain, actions related to situational awareness that necessitate the involvement of the Mission
Command Team or pertain to suspicious situations potentially jeopardising the integrity of the DCM
should be highlighted. These actions warrant specific instructions on how to proceed with the custody
transfer. In such instances, the CTP dendrogram should clearly outline the particular CTP node that
triggered the alert.
This document focuses on the CBRNE digital evidence item transport lifecycle, from collection to its final
destination. Sample collection techniques, preservation and packaging procedures are outside the scope
of this document as they are well documented in existing standards. A well-documented dCoC should be
established through a data governance process and with guidelines to ensure the integrity of the DCM for
each CTP in the dCoC process.
This Part 2 should be considered alongside with Part 1 - Overview and concepts. Together with Part 1 -
Overview and concepts - it is possible to obtain a complete understanding of the custody transfer lifecycle.
1 Scope
This document provides guidelines for managing and auditing Digital Custody Metadata (DCM), enabling
stakeholders to identify and audit custody ownership for CBRNE digital evidence items in the digital chain
of custody (dCoC). It proposes a metadata structure to manage resources assigned to a CBRNE mission
and comply with good data governance practices, raising awareness at each custody transfer point.
The information flow within the dCoC is modelled using the Business Process Model and Notation
(BPMN) to specify the DCM governance workflow. This standard notation provides a formal
representation that helps understand the challenges associated with the DCM. The goal is to focus on the
metadata structures required to manage digital asset custodians while outlining the data to be considered
when specifying a DCM governance workflow.
This document is the second part of two Technical Specifications (TS) on the provision of DCM services
for managing data related to the custody of CBRNE digital evidence items.
2 Normative References
There are no normative references in this document.
3 Terms and Definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
4 Symbols and Abbreviated Terms
AAA Authentication, Authorization, and Accounting
API Application Programming Interface
CC Command Centre
CTP Custody Transfer Point
dCoC digital Chain of Custody
DCM Digital Custody Metadata
GUI Graphical User Interface
ICT Information and Communications Technology
KPI Key Performance Indicator
RAV Remote Aerial Vehicle
RGV Remote Ground Vehicle
ROV Remotely Operated Vehicle
TS Technical Specification
UX User Interface
5 Data Governance in the Digital Custody Transfer Domain
5.1 General
This section provides guidelines for implementing data verification measures, guaranteeing their
availability, integrity, authentication, confidentiality, and non-repudiation. These measures serve the
purpose of creating a digital evidence log, documenting custodianships and the transfer of digital custody
between stakeholders. The digital log constitutes an information assurance storage, enabling auditing of
the data governance workflow while ensuring integrity checks are in place.
Those responsible for data governance, particularly those who need to analyse metadata characterizing
the digital evidence, should seek to create:
• A culture that considers DCM as a valuable digital asset, being accountable for ensuring that legal,
ethical, and other requirements comply;
• Assure that all DCM are harmonized and adequately stored in an evidence log, with the possibility to
query the chronological execution of custody transfer transactions;
• All parties involved in developing policy, planning and implementation should know the causes of
failure associated with DCM processes, their responsibilities, and potential mitigation actions.
Management support is also essential for successfully establishing, implementing, maintaining and
continually improving the DCM process. Management should evaluate existing policies and demonstrate
leadership and commitment to mitigate uncertainty [1]. The goal is to provide a reliable data governance
workflow for each CTP lifecycle.
Figure 1 illustrates that the DCM process is organized into three levels of metadata governance.
Maintaining an appropriate balance between controls and management should be considered for
effective communication with all stakeholders involved in the CBRNE mission. Additionally, any
situational-awareness actions requiring the intervention of the Mission Command Team or associated
with suspicious situations that could potentially compromise the integrity of the DCM should be flagged
for in-depth analysis. These situations should be communicated to all stakeholders, including operational
decision-makers, to enhance awareness and accountability.

Figure 1 — Metadata governance harmonization
Those responsible for metadata harmonization should ensure that DCM processes are controlled
according to the risk criteria and conform to the specified guidelines:
• Promote a shared understanding of various concepts and terminology for the governance of DCM
processes from the viewpoint of the intervenient stakeholders (i.e. different Teams in the dCoC);
• Articulate objectives and structures for digital metadata governance;
• Encourage a practical and cost-effective establishment of DCM processes;
• Provide guidance and best practices to those responsible for executing DCM strategies and policy;
• Identify tasks and strategy contexts for the metadata governance so that it may help in setting policy
and design controls, suggesting ways to avoid adverse effects on reputational factors;
• Promote the proactive use of metrics and risk evaluation practices for minimizing failure in the DCM
processes;
• Provide guidance for compliance, conformance and effectiveness review.
The overriding goal is to help organisations establish good data governance practices for their DCM
processes. Setting up a data governance structure for cross-border functioning and mechanisms for a
coordinated approach between stakeholders helps establish a global and harmonized view of the DCM.
The guidelines also foster the need for cooperation and interoperability between third-party systems to
deliver DCM services seamlessly.
5.2 The Data Governance Process
Data governance allows setting and enforcing controls that would enable greater access to data, gaining
security and privacy from the controls on data. Data governance ensures that data are safe, secure,
private, usable, and compliant with internal and external data policies [2]. It ensures that data are
consistent and trustworthy and does not get misused. Another data governance goal is to ensure data are
used correctly, blocking potential misuse of sensitive information [3]. That can be accomplished by
creating uniform data policies on the use of data, along with procedures to monitor usage and enforce the
policies continuously.
The data governance policies should be developed, along with rules that define how data can be used by
authorized personnel [4]. In addition, controls and audit procedures are needed to ensure ongoing
compliance with internal policies and external regulations and guarantee that data are used consistently
across applications.
In the DCM governance workflow, it is essential to be aware of and mitigate specific causes of failure
which can compromise the dCoC. The DCM governance workflow aims to avoid negative consequences,
including those described below:
• Breaches of privacy caused by inappropriate methods or accidental/non-compliance disclosure;
• Original damage to DCM caused by improper methods, including the damage to data integrity,
authenticity, reliability or usability; and any other potential causes of spoliation;
• Inconsistency in the data structure caused by inappropriate disclosure to any third parties;
• Damage or non-compliant management of the evidence chain can render the DCM inadmissible in
court.
These risk assessments prevent or reduce undesirable effects and deliver continuous improvement. It
requires an evaluation of the internal and external context (including business, legal and jurisdictional
issues, and ICT infrastructure).
In addition to the risk assessment, metrics for monitoring the execution of DCM processes have to be
established. These metrics should monitor progress and compliance with defined requirements to ensure
the expected outcomes within the dCoC process. Appropriate use of metric-based monitoring can indicate
whether particular targets (e.g. critical dates or who owns the custody at each CTP) are likely to be met.
Consultations with the external parties and the stakeholders that can be adversely affected by the DCM
processes can help set the metrics.
In a CTP, multiple entities may access digital evidence items during the dCoC process. Therefore, when
managing digital evidence, it is relevant to know who owns the custodianship of what digital evidence
[5]. Consequently, for each CTP, the DCM should provide the following:
• Integrity, the digital evidence has not been altered or corrupted during the transfer.
• Traceability, the digital evidence should be traced from the time of its collection until it is destroyed.
• Authentication, all the resources (e.g. authorized stakeholders and equipment) interacting with the
digital evidence should provide irrefutable and recognizable proof of their identity.
• Verifiability, the data governance process should be verifiable by every stakeholder involved.
• Security, changeovers of digital evidence cannot be altered or corrupted.
The evidence log should provide integrity checks (i.e. every CTP can verify and detect if there has been
an integrity breach that would invalidate the digital evidence transfer). A smart contract to keep track of
ownership changes should be implemented for the dCoC (see Part 1 for more information about smart
contracts).
5.3 The Custody Transfer Lifecycle
The CTP is a vital element within the DCM process. It is designed to ensure verifiable integrity and
traceability of ownership. To achieve this, the CTP involves the active participation of two role-assigned
Resources: the custody owner and the custody receiver. Both Resources are required to acknowledge the
DCM information to complete a custody transfer successfully.
If only one of the Resources acknowledges the data, it triggers a non-conformity situation. Consequently,
the system assesses the risk level and prompts the user to provide a comment identifying the detected
inconsistency in the DCM. This triggers the need to abort the normal execution of the custody transfer. In
such cases, custody is assumed temporarily to ensure the packet's delivery to the next CTP. Since digital
evidence can be compromised during this period, analysing it as soon as possible should be a priority.
Figure 2 provides a high-level view of the data governance process [6] that should be performed for each
CTP. The data verification process includes the following aspects:
• Validate the CTP data regarding the assigned CBRNE mission;
• Validate the package data, including the data describing the sample bags that the package holds;
• Validate the Resources data, meaning verify the data relating to the custody owner and receiver.
If an inconsistency or any other suspicious situation is identified in the reported information within the
DCM, there is a potential risk of unauthorised data alteration. The Mission Command Team should be
informed regarding this situation so that they can provide appropriate instructions on the next course of
action. The data governance process of the CTP should include mechanisms to report such situations and
reject the custodianship of the CTP. The CTP data governance process presented in Figure 2 maps the two
possible use cases:
• Use Case 1: if no data inconsistency is reported (Figure 2.a), the CTP is successfully completed. In this
case, the DCM should be updated to reflect the new custody owner. This updated information should
be visually represented in the CTP dendrogram, allowing the Mission Command Team to verify the
successful execution of the CTP easily.
• Use Case 2: in the event of a reported data inconsistency (Figure 2.b), the CTP is not successfully
completed, and an alert should be promptly sent to the Mission Command Team. They can then
analyse the reported inconsistencies and provide instructions on how to proceed with the custody
transfer. At this point, to prevent disruption of the dCoC, custody is conditionally assumed until the
package reaches its final destination or until an intermediate Laboratory Team assesses the impact
of the reported inconsistency.

Figure 2 — High-level view of the CTP data governance process
A data inconsistency should be reported whenever the information in the DCM for the corresponding CTP
is not validated by one of the assigned Resources (i.e. custody owner or custody receiver). The CTP node
in the dendrogram should be displayed as unsuccessful, and the Mission Command Team should be
notified to provide instructions on how to proceed. As presented in Table 1, the severity level for a data
inconsistency should be indicated in the alert message.
Table 1 — Levels of severity when reporting a data inconsistency
Severity Level Description
Level 1: This is the most severe level whereby the CTP data governance was
interrupted because the custody receiver detected an inconsistency after
sample package
analysing the condition of the physical package. The package metadata does
inconsistency
not match what is perceived/observed on the actual package (e.g. the seal is
broken or does not match what is in the DCM, the package type does not match
what is presented in the DCM, or any other package data inconsistency). At this
level, the integrity of the sample package is compromised.
Level 2: The CTP data governance was interrupted because one of the Resources
(i.e. custody owner or custody receiver) detected an inconsistency in the DCM
custodianship
data characterizing the Resource assigned to deliver or receive the package.
inconsistency
Any suspicious situation that may compromise the custodian data (e.g. the
clearance level does not comply, the person metadata does not match with the
person delivering/receiving the package, or any other Resource data
inconsistency). At this level, the sample package is not compromised;
nevertheless, the status of the CTP in the dendrogram should be marked as
unsuccessful for further auditing of the reported inconsistency.
Level 3: The CTP data governance was interrupted because one of the Resources
(i.e. custody owner or custody receiver) detected an inconsistency in the DCM
Mission
data regarding the assigned mission (e.g. the mission identifier is not correct,
inconsistency
the date is not correct or any other mission data inconsistency). At this level,
the sample package is not compromised; nevertheless, the status of the CTP in
the dendrogram should be marked as unsuccessful for further auditing of the
reported inconsistency.
Level 4: Because of security issues, the CTP data governance should be interrupted if
no activity is reported for more than the defined timeout period. A timeout
Timeout event
event should be triggered, and the CTP process should be marked as
unsuccessful because of a timeout event. In this case, both Resources should be
able to access the CTP to complete its execution successfully. At this level, the
sample package is not compromised.
Additional guidelines for monitoring the CTP data governance process relate to the clearance level of the
Resources assigned to a CTP:
• A validation procedure should be implemented to check the clearance level of the registered user,
and verify if the logged user is authorized to create a new CTP within the dCoC, activate an existing
CTP or analyse the evidence log of a CTP already closed;
• The CTP should not allow unauthorised Resources to access the DCM or any data within the CTP
dendrogram. Moreover, each digital evidence access should verify if the Resource is authorized to
perform such tasks according to its role;
• To access an existing CTP, the logged user should provide an authorization code to access the user
interface (GUI) that includes information about the CTP.
5.4 CTP Lifecycle
5.4.1 CTP Status Management
When a new CTP is created, it involves the addition of a specific node to one of the branches in the CTP
dendrogram. The Mission Command Team, responsible for managing the CTP dendrogram, should
provide all the necessary information to comprehensively describe the CTP when adding it to the CTP
dendrogram. This information is then stored in the DCM associated with the respective CTP.
The BPMN diagram in Figure 3 presents a global view of the CTP lifecycle. The diagram assumes that the
Mission Command Team has previously configured the information about the selected CTP. This implies
that the DCM associated with the specific CTP contains the essential contextual details required by the
stakeholders to navigate through the various stages of the CTP lifecycle successfully.
The diagram illustrates the step-by-step process required for a successful custody transfer. This process
applies to both the custody owner and the custody receiver. To access the detailed description of the CTP,
stakeholders shall provide an access code, which serves as an additional security measure for tracking
digital evidence during the dCoC process. The diagram includes an event-based gateway that represents
three possible outcomes:
• Timeout event, this event is triggered when no action is taken within a predetermined time period.
Consequently, the layout containing the detailed metadata of the CTP will be closed.
• Validate event, this event allows stakeholders to confirm the accuracy of the metadata describing the
digital evidence item. Once the data are validated, the interface should allow the custody receiver to
accept the custodianship of the digital evidence item. This action will result in a change in the CTP
status. This step only applies to custody receivers.
• Reject event, this event empowers stakeholders to report any inconsistencies detected in the DCM.
When reporting an inconsistency, stakeholders should provide details about the identified
inconsistency. This reporting mechanism facilitates the Mission Command Team in gaining
situational awareness.
If the sequence flow is executed successfully, the custody transfer is effected, and the custody receiver
assumes the ownership of the digital evidence item. Consequently, the CTP status will be updated
accordingly. It is crucial to store this operation to ensure non-repudiation for data governance and
auditing purposes.
A standard Business Process Model and Notation (BPMN) provides a standard graphical notation for representing
the information workflow. It provides ability to communicate internal business procedures in a standard manner.
Furthermore, the graphical notation facilitates the understanding of the performance collaborations and business
transactions between the organizations, source OMG: www.bpmn.org.
Figure 3 — A process describing the CTP lifecycle tasks
In Figure 3, the subprocess “A2: Display CTP Metadata” is intended to offer stakeholders a comprehensive
overview of the selected CTP. The design of this interface should prioritize providing stakeholders with
complete information about the CTP. For further guidance on constructing this interface, Section 5.4
contains additional details regarding the data structure that should be taken into account.
The sequence flow regarding the subprocess “A2: Display CTP Metadata” is presented in Figure 4. The
diagram outlines the following two user tasks:
• A1: Present CTP Metadata, this task should provide information regarding the CTP node, a summary
of the data characterizing the packages included in the DCM, and a complete description of the
stakeholders assigned by the Mission Command Team to the CTP;
• A2: Display Selected Package Metadata, this task should provide detailed information regarding the
package and the sample bags inside the package.
If a stakeholder identifies any inconsistencies or suspicious situations, there should be a provision to
report such information. This reporting mechanism should allow stakeholders to include visual evidence
in the form of images, providing a tangible representation of the reported situation. By incorporating
visual evidence, stakeholders can enhance the accuracy and clarity of their reports, facilitating a more
comprehensive understanding of what is being reported.

Figure 4 — Sequence flow regarding the subprocess Display CTP Metadata
The diagram in Figure 5 depicts the sequence flow for the subprocess “A3: Report Custody Rejected” in
the BPMN diagram. The diagram includes an ad hoc task outlining the steps for rejecting a CTP's
custodianship. This ad hoc task enables stakeholders to provide the necessary actions and explanations
for selecting the CTP reject option, thereby facilitating the Mission Command Team in gaining situational
awareness. The reason/justification for the rejection should be stored in the CTP metadata.
Figure 5 — Sequence flow regarding the subprocess Report Custody Rejected
The dendrogram's CTP status needs to be regularly updated to reflect the outcome obtained throughout
the execution process of the CTP lifecycle. This ensures that the CTP node within the dendrogram
accurately represents its current state. If the CTP has successfully concluded, the corresponding node
should be marked as such. However, if the CTP is still pending, it should be labelled as awaiting
instructions from the Mission Command Team, who will provide guidance on how to proceed.
5.4.2 CTP Global Process
Figure 6 provides a detailed view of the activities that should be implemented for the CTP global data
governance process. The diagram also outlines the informational artefacts (Data Store) that should be
considered to store the information generated within the process. Because of data security reasons,
Resources assigned to a mission as custodians should only visualize the list of CTPs assigned to them
(see tasks A1 and A2). Before allowing a Resource to access the CTP data, a double authentication process
should be provided, requiring the Resource to:
• Provide a code to access the information for the selected CTP (see task A3);
• After presenting the CTP data, if no activity is detected, a timeout event should be triggered (see task
A4);
• Acknowledge the information provided by the DCM for the selected CTP (see task A5).
For a custody transfer to be successful, the custody receiver should accept the custodianship explicitly.
A timeout event should be triggered if no activity is detected (see task A6).
Figure 6 — The CTP data governance process for a specific Mission
The data governance process presented in Figure 6 assumes the existence of a data secure validation
process (see tasks A1 and A3), able to record any suspicious or non-authorized access (see task A10). If
a DCM inconsistency is reported, a non-conformity should be triggered, causing the system to determine
the risk level and requesting the user to enter a justifying comment (see tasks A8 and A9). Any non-
conformity or suspicious situation should be registered in the evidence log (CTP Risk Log), triggering an
alert message to the Mission Command Team.
Resources cannot freely join the dCoC for a specific Mission; instead, they should be pre-emptively
assigned and integrated within an authorized user group (authGroup) to access any CTP within the dCoC
process. This authorization process is often used in permission-based approaches [1]. The analyse of the
BPMN diagram in Figure 6 should also consider the following assumptions:
• Digital evidence items are collected by a Resource (e.g. Sample Team) who becomes the (first)
custody owner;
• During the dCoC process, several Resources (e.g. Carrier Team) may need to accept the digital
evidence's custodianship temporarily;
• A digital custody metadata evidence (dcmEv) should include metadata characterizing the Resource
(i.e. an authorized entity that can access the CTP). It identifies the current custodian of a physical
package or any other probative information stored or transmitted digitally (e.g. measurement data).
It identifies the digital evidence item owned by that Resource at each time.
To update the DCM database with a new dcmEv record, the CTP data governance process should be
validated, considering:
• If a Resource (authResource) needs to become the custodian of a specific digital evidence item (dEv),
the current custodian should acknowledge the transfer request towards the authResource;
• Each authResource has a unique public identifier (resID) known to all. They own private credentials
(perCode) that allow them to be authenticated and take action in the dCoC process;
• At each time (t), dEv can have just one owner, and the owner should belong to an authorized
entity/organization;
• The change of ownership happens if and only if:

authResource∈authGroup∧∈dcmEυ DCM Database
The transfer record (dcmEv), with the corresponding custodianship for the dEv, is written permanently
to the DCM database. This transaction log allows for tracking digital evidence during the dCoC process
for a specific Mission. It is characterized by a reduced size of records to be stored and is subjected to a
high update frequency.
5.5 Authentication and verification of assigned resources
The dCoC process is a chain of responsibility where custodians (i.e. authorized Resources) of a CBRNE
digital evidence item need to document the continuity of possession of that evidence for a specific CTP
[7]. When designing the GUI to validate the custodianship, it is essential to consider:
• For each CTP, the GUI should provide the data for auditing the digital evidence transfer;
• For each CTP process, the traceability of custodianship should be available within the evidence log;
• Because of security issues, any situation that might compromise the integrity of the digital evidence
should be reported in the evidence log, triggering an alert message to the Mission Command Team
as well as to all operational decision-makers.
For each CTP, the specified GUI should provide information according to Table 2 guidelines.
Table 2 — Metadata structure considerations for each section
GUI Section Metadata Description
metadata identifying the CTP and the assigned mission. Recommended attributes:
• CTP ID, the unique identifier of the CTP within the assigned mission
• CTP Date, the date the CTP is expected to be initiated by one of the Resources
• CTP Location, information regarding the location of the CTP (e.g. geographical
coordinates - latitude and longitude)
• CTP address, a text identifying the place of the CTP location
• CTP motive, description explaining the CTP motive
Mission
• Mission Name, Mission Description and Mission Type
• CTP Custody Validation, a timestamp indicating when the Resource acknowledged
the CTP data. This could be presented as a timeline to show the instant each
Resource acknowledged (or rejected) the CTP data
o CTP timestamp of the DCM validation by each stakeholder (i.e. the custody
owner and the custody receiver)
o CTP acceptance timestamp signals the instance the custody receiver
accepts the custodianship of the CBRNE evidence items.

resID, see the domain model diagram in Annex A for more information.
GUI Section Metadata Description
metadata characterizing the physical or digital evidence item during transportation.
It encompasses a collection of metadata that describes both the package itself and the
sample bags contained within the package. Recommended attributes:
Package • Package ID, unique identifier of the package. This information can
include a QR code to simplify automatic readings by devices equipped
with a QR code reader.
• Package Type, identification of the type of package container (e.g.
standard, refrigerated, radiologic selling container, etc.).
• Package seal, indication if the package is sealed. This information
should include data related to the date/time, the mission's name/code,
and the entity responsible for issuing the package seal. Images of the
sealed status should also be provided in addition to pictures of the
package.
• Package dimensions, identifying the length/ height/width of the
package.
• Package weight.
• Package Carrier Instructions, text with instructions for transporting the
Package and
package (e.g. fragile package must be transported at a temperature of
Sample Bags
−10° C).
• Total Sample Bags, the total number of sample bags.
• Package Comments, optional text attribute to add any information
related to the package container (e.g. report any damage or scratches
observed or any other pertinent information to be included in the dCoC
report).
Obs.: Should include the possibility of uploading pictures of the package.
Sample • Sample Bag ID, a unique identifier of the sample bag. This information
Bag can include a QR code to simplify automatic readings by devices
equipped with a QR code reader.
• Date/time, data reporting the date and time the sample was collected.
• Bag type, identification of the type of sample container.
• Sample Team, information about the sampling team responsible for
collecting the sample at the site scene.
• Sample Description, optional text attribute to add information related
to the collected sample.
Obs.: Should include the possibility of uploading a scan of the Sample Team
(Compiler) report.
GUI Section Metadata Description
metadata identifying the Resources assigned to the CTP. The goal is to guarantee that
the digital evidence remains under the control of an authorized individual and is never
unaccounted for. This objective can be achieved by including two sections in the
process: one containing information about the custody owner and another containing
information about the custody receiver. Recommended attributes:
• Role, indicates the role of the stakeholder (e.g. custody owner or receiver,
equipment resource with access to digital measurements, etc.).
• Name, indicates the person's name if it is a human stakeholder. In some
specific situations, the Resource can be equipment; in this case, additional data
should be considered (e.g. brand, model, registration number or any other
identifier).
Stakeholders
• Entity, indicates what organization/entity the Resource represents.
• Picture, an attribute with a photo of the Resource. In some situations, the
entity's logo might replace the picture because of security.
• Contact data of the custody receiver, including (mobile)phone number and the
complete address of the affiliated entity.
The custody owner might be:
• The Sample Team, if it refers to the first CTP in the dCoC process.
• The Carrier Team, if it relates to an intermediate CTP in the dCoC process.
• The Laboratory Team, if it relates to an intermediate destination where the
original samples might be split. By default, the last custody owner should be
the final destination.
The DCM process aims to establish that unauthorised individuals could not access or possess digital
evidence. It should also ensure the integrity and authenticity of the evidence. To achieve this, it is
advisable to implement a data-evidence documentation framework that captures and records every
instance of digital evidence transmission between stakeholders [8]. While there is no limit on the number
of transfers between stakeholders, it is recommended to minimize the number of transfers whenever
possible. For more detailed information regarding the data structure to verify the custodianship of digital
evidence, see the domain model provided in Annex A.
5.6 Managing Resources Assigned to the Mission
The Mission Command Team is responsible for coordinating the tasks within the dCoC. They should be
responsible for assigning or removing a Resource to/from a specific Mission. The assignment of
Resources to a Mission should follow a permission-based approach. Posting a resource to the mission
should consider a role-permission matrix to control authorization requirements (see Annex B).
The graphical user interface (GUI) for assigning resources to a mission within the dCoC workflow should
also prioritize user experience (UX) requirements to ensure that the Mission Command Team can
efficiently manage resources from the mission command centre. A well-designed GUI can also contribute
to improving the information at each CTP.
The interface should allow the Mission Command Team to swiftly assign or remove resources for a
particular mission while adhering to the role-permission matrix for authorization control. It should be
designed to simplify setting specific resources to the CTP dendrogram, ensuring a seamless and efficient
chain of custody process (refer to Annex D for further details). To facilitate user-friendliness and effective
resource management, the GUI should incorporate dynamic management functionalities that promptly
alert the Mission Command Team whenever their intervention or attention is ne
...