Wiki source code of Guidelines for Confidentiality and Embargo in SDMX

Version 2.6 by Helena K. on 2026/01/27 13:02

version	line-number	content
1.1	1	{{box title="Contents"}}
	2	{{toc/}}
	3	{{/box}}
	4
	5	= Document History =
	6
2.2	7	(% style="width:1039.96px" %)
	8	\|Version\|(% style="width:110px" %)Date\|(% style="width:856px" %)Comment
	9	\|1.0\|(% style="width:110px" %)21/8/2015\|(% style="width:856px" %)Initial version.
	10	\|2.0\|(% style="width:110px" %)7/3/2018\|(% style="width:856px" %)(((
1.1	11	Replaced the “Embargo: Privileged access” use case confidentiality status to use CONF_STATUS:E instead of CONF_STATUS:N. When this guideline is implemented, the CONF_STATUS:N can no longer be used for this use case (the embargo time is ignored if the CONF_STATUS is N).
	12
	13	Clarified the document text, removed superfluous text.
	14
	15	Added use of time zone is recommended.
	16	)))
	17
	18	= Introduction =
	19
2.2	20	This paper presents use case scenarios related to confidentiality and embargo in SDMX data exchanges, and provides recommendations on how to represent these elements in the SDMX model. The aim is to provide a consistent and practical way to represent these aspects in SDMX artefacts in order to promote cross-domain consistency, and harmonise methodology and processes.
1.1	21
	22	Confidentiality aims at protecting data from unauthorised disclosure that could be prejudicial or harmful to the interest of the source or other relevant parties.
	23
	24	Embargo means that data may become public only after expiry of a pre-defined date and time.
	25
	26	Embargo establishes a relationship between a set of data (e.g. an observation), a date/time and a group of privileged data recipients.
	27
	28	Disclosure of data marked as confidential or under embargo is not permitted. Procedures should be in place to prevent such disclosure, including rules for staff, aggregation rules when disseminating data, provision of unit records, etc.
	29
	30	There needs to be a formal agreement between organisations involved in the exchange of confidential data in order to prepare systems and workflows.
	31
	32	Data exchange partners are advised to agree up front on the usage of the embargo mechanism(s) for specific data messages.
	33
	34	The embargo CONF_STATUS value “E” is not recommended for final dissemination to users but only for data exchange.
	35
	36	= Use Cases =
	37
2.2	38	This section describes the confidentiality and embargo use cases that are addressed by these guidelines. The use cases and embargo SDMX representations are summarised in annex 1:
1.1	39
	40	== Use case 1: Non-confidential data ==
	41
	42	Data is available to the public immediately, meaning that data is not confidential and there is no embargo.
	43
	44	The data’s CONF_STATUS attribute should be set to “Free (free for publication)”.
	45
2.4	46	{{box}}
2.5	47	SDMX representation
1.1	48
2.4	49	* CONF_STATUS: F
	50	{{/box}}
1.1	51
	52	== Use case 2: Confidential data ==
	53
	54	=== Exchange of confidential data without embargo nor forwarding to secondary recipients ===
	55
2.2	56	One or more observations in the data message are confidential. Embargo does not play a role in this scenario. Depending on arrangements between data exchange partners, this data can be made available to privileged data users.
1.1	57
2.2	58	The observation’s CONF_STATUS attribute should use a specific code denoting the confidential character of the information. Below are some examples of such confidentiality statuses{{footnote}}For a full list of confidentiality statuses, see https://sdmx.org/wp-content/uploads/CL_CONF_STATUS_1_2_2018.docx{{/footnote}}:
1.1	59
2.2	60	* N: Not for publication, restricted for internal use only. Used to denote observations that are restricted for internal use only within organisations
	61	* C: Confidential statistical information (primary confidentiality) due to identifiable respondents
	62	* D: Secondary confidentiality set by the sender, not for publication
	63	* A: Primary confidentiality due to small counts
1.1	64
	65	=== Forwarding confidential data to secondary recipients ===
	66
	67	A sender sends confidential data to certain primary recipients, and allows those to forward the confidential data to a restricted and pre-defined set of secondary recipients.
	68
2.2	69	The observation’s CONF_STATUS attribute should be marked as “Not for publication, restricted for internal use only”. An additional observation-level attribute: CONF_REDIST, defines the secondary recipient(s) to whom the sender allows the primary recipient to forward confidential data{{footnote}}Example: National statistical institute XX reporting data to Eurostat indicates that Eurostat can forward those data to the ECB, IMF and OECD. More complex use case: The reporting organization specifies that Eurostat can forward those data only to the ECB Statistics Department, thus excluding all other organisations as well as all other ECB departments.{{/footnote}}. See section Use of the CONF_REDIST attribute for the appropriate coding of this attribute.
1.1	70
	71	The forwarding of confidential data is represented as follows in SDMX:
	72
	73	\|(((
1.2	74	(% class="wikigeneratedid" id="HSDMXrepresentation-1" %)
	75	SDMX representation
1.1	76
	77	* CONF_STATUS: N;
	78	* CONF_REDIST (Observation, Conditional): [Organisation(s)];
	79	)))
	80
	81	=== Adding embargo information to a data message ===
	82
	83	Following the definition of embargo, the recipient must keep the data confidential until a pre-defined point in time (embargo) when it becomes public.
	84
	85	Two cases can be distinguished:
	86
	87	* Allowing privileged access to embargoed data
	88	* Enabling the frontloading of data into systems
	89
	90	//Allowing privileged access to embargoed data//
	91
	92	If the goal is to allow the data recipient to have privileged access to embargoed observations in a data message (message), the embargoed observation’s CONF_STATUS attribute should be coded as “E: Not for publication until the embargo time expires; free for publication after the embargo time expires.” with an observation level attribute EMBARGO_TIME (date/time/time zone).
	93
	94	\|(((
1.2	95	(% class="wikigeneratedid" id="HSDMXrepresentation-2" %)
	96	SDMX representation
1.1	97
	98	* CONF_STATUS: E;
	99	* EMBARGO_TIME (Observation, Conditional): [timestamp]
	100	)))
	101
2.2	102	Including a time zone is strongly recommended and the best case is to use the UTC (Coordinated Universal Time) time standard. However, if no time zone is provided then the time zone of the recipient is assumed.
1.1	103
	104	These two examples represent the same time for a recipient established in the Central European time zone (e.g. Germany, Norway, Gibraltar):
	105
	106	* (Recommended) With UTC indicator: 2017-12-15T14:02:29Z
	107	* With timezone indicator: 2017-12-15T15:02:29+01:00
	108
	109	//Enabling the frontloading of data into systems//
	110
2.2	111	If the goal is to allow frontloading of a whole data message into systems so that the data can be made visible to users at the expiry of the embargo date/time, the header section of the message should contain an embargo date/time attribute. This implies that all information in the data message is under the embargo date/time set in the header. The header attribute EmbargoDate with format date/time/time zone indicates until when the whole data message received cannot be shared with any recipient users.
1.1	112
	113	Once the EmbargoDate in the header elapses, each observation’s confidentiality status becomes that which is marked in the CONF_STATUS attributes.
	114
2.2	115	Note that this scenario presumes that all data in the message cannot be viewed before the header EmbargoDate, and that there is no privileged access before this time. However, observations may be marked with any other confidentiality status that is valid after the frontloading EmbargoDate elapses.
1.1	116
	117	\|(((
2.1	118	(% class="wikigeneratedid" id="HSDMXRepresentation" %)
	119	SDMX Representation
1.1	120
	121	* CONF_STATUS: <Set to the required confidentiality status after the embargo time elapses>; <Header>\<EmbargoDate>: [timestamp]
	122	)))
	123
2.2	124	The two ways of representing embargoed data exist to provide efficiency in the exchange, allow for differentiating data intended to be frontloaded and data aimed to be provided in advance to a restricted audience, and provide flexibility when few observations need to be embargoed in a large data message. The trade-off is the complication of system implementation to support the two representations of embargo, which has to be done locally on a case-by-case basis.
1.1	125
	126	= Additional recommendations and examples =
	127
2.2	128	In data flows that feature confidential data, CONF_STATUS is highly recommended to be a mandatory attribute. However, if CONF_STATUS is optional in the DSD and missing from an observation, it is always implied to be “F” (free).
1.1	129
	130	=== Use of the CONF_REDIST attribute ===
	131
2.2	132	The CONF_REDIST attribute defines the secondary recipient(s) to whom the sender allows the primary recipient to forward confidential data. It is recommended to be an optional attribute at observation level. Ideally it should reference a shared code list containing standard organisation codes. To allow several secondary recipients there are these possibilities:
1.1	133
2.1	134	Use a code that represents multiple organisations, or;
1.1	135
2.2	136	Use several CONF_REDIST attributes to portray the multiple recipients. Each attribute represents one recipient and references the same codelist. This implementation is cleaner than the above point 1, though this will require adding as many attributes to your DSD as there are potential recipients of the redistributed confidential data.
1.1	137
	138	If the EMBARGO_TIME and CONF_REDIST attributes are both used:
	139
	140	1. Data is available only to the organisations in CONF_REDIST until EMBARGO_TIME
	141	1. Data is available to the public after EMBARGO_TIME
	142
	143	\|(% colspan="3" %)(((
2.1	144	(% class="wikigeneratedid" id="HPrivilegedAccess" %)
	145	Privileged Access
1.1	146	)))
	147	\|Use case\|No forwarding\|Forwarding
	148	\|Embargo\|(((
	149	CONF_STATUS: E
	150
	151	EMBARGO_TIME
	152	)))\|(((
	153	CONF_STATUS: E
	154
	155	EMBARGO_TIME
	156
	157	CONF_REDIST
	158	)))
	159	\|No embargo\|CONF_STATUS: N\|(((
	160	CONF_STATUS:N
	161
	162	CONF_REDIST
	163	)))
	164
	165	=== An example of sending data for privileged access with data forwarding information ===
	166
	167	This example describes a case where data needs to be embargoed until a certain date and time, and may be sent to certain other organisations in a single transmission without modification of the data or attributes.
	168
	169	This example is based on the exchange of sector accounts statistics within the European statistical system.
	170
	171	* The national statistical institutes send data to Eurostat, and allow the data to be shared with the ECB for statistical coproduction
	172	* The data may only be shared with the public on the next day
	173
	174	CONF_STATUS:E;
	175
	176	CONF_REDIST: ECB;
	177
	178	EMBARGO_TIME=<T+1 day, e.g. 2017-12-15T10:00:00Z>
	179
2.2	180	The solutions suggested above aim at covering the most common confidentiality and embargo use cases within a single transmission from the primary reporter to the primary recipient. However, for some more complex scenarios it might still be required to make multiple transmissions.
1.1	181
	182	It is strongly recommended that use cases are specified in an agreement between organisations involved in regular transmissions up-front in order to avoid unnecessary delay in data publication or – much worse – confidentiality breaches.
	183
	184	Annex 1: SDMX Representation of the confidentiality use cases
	185
	186	\|(((
2.1	187	(% class="wikigeneratedid" id="HUsecase" %)
	188	Use case
1.1	189	)))\|(((
2.1	190	(% class="wikigeneratedid" id="HCONF_STATUS28Observation29" %)
	191	CONF_STATUS (Observation)
1.1	192	)))\|(((
2.1	193	(% class="wikigeneratedid" id="HAdditionalattributes" %)
	194	Additional attributes
1.1	195	)))\|(((
2.1	196	(% class="wikigeneratedid" id="HRemarks" %)
	197	Remarks
1.1	198	)))
	199	\|(((
2.1	200	(% class="wikigeneratedid" id="HNon-confidentialdata" %)
	201	Non-confidential data
1.1	202	)))\|(((
2.1	203	(% class="wikigeneratedid" id="HF" %)
	204	F
1.1	205	)))\|(((
	206	== ==
	207	)))\|(((
	208	== ==
	209	)))
	210	\|(((
2.1	211	(% class="wikigeneratedid" id="HConfidentialdatawithnoembargo" %)
	212	Confidential data with no embargo
1.1	213	)))\|(((
2.1	214	(% class="wikigeneratedid" id="HC3BD3BS3BA3BO3BT3BG3BM3BN" %)
	215	C;D;S;A;O;T;G;M;N
1.1	216	)))\|(((
2.1	217	(% class="wikigeneratedid" id="H-2" %)
	218
1.1	219	)))\|(((
2.1	220	(% class="wikigeneratedid" id="HCONF_STATUSwillusuallybeCbutmayalsobeD3BS3BA3BO3BT3BG3BM3BNdependingontherequiredstatusandconfidentialityreason.A0SeetheCL_CONF_STATUScodelistfordetails5B35D" %)
2.2	221	CONF_STATUS will usually be C but may also be D;S;A;O;T;G;M;N depending on the required status and confidentiality reason. See the CL_CONF_STATUS code list for details{{footnote}}https://sdmx.org/wp-content/uploads/CL_CONF_STATUS_1_2_2018.docx{{/footnote}}
1.1	222	)))
2.1	223	\|(((
	224	Forwarding of confidential data
	225	)))\|(((
	226	N
	227	)))\|(((
1.1	228	CONF_REDIST: (Observation, Conditional)
	229
	230
	231	)))\|CONF_REDIST may represent multiple organisations
	232	\|(((
2.1	233	(% class="wikigeneratedid" id="HEmbargo:Privilegedaccess" %)
	234	Embargo: Privileged access
1.1	235	)))\|(((
2.1	236	(% class="wikigeneratedid" id="HE" %)
	237	E
1.1	238	)))\|(((
2.1	239	(% class="wikigeneratedid" id="HEMBARGO_TIME28Observation2CConditional29" %)
	240	EMBARGO_TIME (Observation, Conditional)
1.1	241
	242
	243	)))\|Only the observations with an EMBARGO_TIME attribute are embargoed. After the embargo time elapses, the data are free for publication (equivalent to F status).
	244	\|(((
2.1	245	(% class="wikigeneratedid" id="HEmbargo:Privilegedaccesswithforwarding" %)
	246	Embargo: Privileged access with forwarding
1.1	247	)))\|(((
2.1	248	(% class="wikigeneratedid" id="HE-1" %)
	249	E
1.1	250	)))\|(((
	251	EMBARGO_TIME (Observation, Conditional)
	252
2.1	253	(% class="wikigeneratedid" id="HCONF_REDIST:28Observation2CConditional29" %)
	254	CONF_REDIST: (Observation, Conditional)
1.1	255	)))\|(((
2.1	256	(% class="wikigeneratedid" id="HOnlytheobservationswithanEMBARGO_TIMEattributeareembargoed.Aftertheembargotimeelapses2Cthedataarefreeforpublication28equivalenttoFstatus29." %)
2.2	257	Only the observations with an EMBARGO_TIME attribute are embargoed. After the embargo time elapses, the data are free for publication (equivalent to F status).
1.1	258
2.1	259	(% class="wikigeneratedid" id="HCONF_REDISTmayrepresentmultipleorganisations" %)
	260	CONF_REDIST may represent multiple organisations
1.1	261	)))
	262	\|(((
2.1	263	(% class="wikigeneratedid" id="HEmbargo:Frontloading" %)
	264	Embargo: Frontloading
1.1	265	)))\|(((
2.1	266	(% class="wikigeneratedid" id="HSettotherequiredconfidentialitystatusaftertheembargotimeelapses." %)
	267	Set to the required confidentiality status after the embargo time elapses.
1.1	268	)))\|(((
2.1	269	(% class="wikigeneratedid" id="H3CHeader5CEmbargoDate3E:5Btimestamp5D" %)
	270	<Header\EmbargoDate>: [timestamp]
1.1	271
	272
2.1	273	)))\|(((
	274	There is no EMBARGO_TIME attribute as the whole message is embargoed with no privileged access.
	275	)))
1.1	276
	277	----
	278
2.1	279	{{putFootnotes/}}