Enforcement Document Production Guide

PART I – OVERVIEW
1. Purpose of this Guide
Part II – WORKING WITH ENFORCEMENT STAFF ON RECORD PRODUCTION
2. Working with Enforcement Staff
3. Forms of Available Production Methods
4. Redactions
5. Handling Inadvertent Production of Privileged Documents
6. Privilege
7. Privilege Log
PART III – ORGANIZATION AND DELIVERY OF ELECTRONIC STORED INFORMATION
8. Organization of Records Produced in Response to Request for Information
9. Secure File Transmission
PART IV – REQUIREMENTS FOR PRODUCING ELECTRONIC STORED INFORMATION
10. Key Requirements
11. Acceptable File Formats
Part V – INSTRUCTIONS FOR E-DISCOVERY PRODUCTIONS
12. Metadata
13. File Structure
14. Bates Numbering
PART VI – PRODUCTION OF HARD COPY RECORDS
15. Scanning and Digitization of Paper Records
16. Producing Original Hard Copy Records
APPENDIX A – METADATA
APPENDIX B – ACCEPTABLE FILE FORMATS
APPENDIX C – KEY TERMS

PART I – OVERVIEW

The Document Production Guide is intended to assist individuals and Dealer Members with submitting documents, correspondence and other records to Enforcement Staff of the Canadian Investment Regulatory Organization (“Enforcement Staff”). It outlines Enforcement Staff’s preferred methods for the production and delivery of Electronically Stored Information (“ESI”), records and documents requested pursuant to CIRO rules.

This Guide applies to requests made in connection with the Canadian Investment Regulatory Organization’s (“CIRO”) investigations, whether:

In response to a Request for Information pursuant to the Investment Dealer and Partially Consolidated Rule 8100 or Mutual Fund Dealer Rule 6; or
Information provided voluntarily.

1. Purpose of this Guide

Enforcement Staff may issue a written Request for Information (“RFI”) requesting books, records, client files and other documentation, related to the Regulated Person’s business.1

This Guide sets out the procedures for preparing and submitting records in reply to an RFI, in a manner that is efficient for both Enforcement Staff and the Regulated Person.

These procedures are essential to:

Preserve data and metadata to maintain integrity and reliability of records;
Minimize processing delays by reducing the time the Regulated Person spends on clarifications, follow-ups and resubmissions; and
Enhance the efficiency and integrity of the investigation process, ensuring timely location, search and analysis of evidence.

Part II – WORKING WITH ENFORCEMENT STAFF ON RECORD PRODUCTION

2. Working with Enforcement Staff

Questions regarding the scope or interpretation of an RFI should be directed to the Enforcement Staff member identified in the request. Early clarification of terms and expectations contributes to greater efficiency and reduces administrative burden and cost for all parties.

While this guide outlines Enforcement Staff’s required formats, alternative formats may be considered upon agreement. Contact Enforcement Staff to discuss production criteria such as scope, format and timelines.

3. Forms of Available Production Methods

Enforcement Staff require that records be produced in the native formats but recognize that alternative methods may be used in certain circumstances, provided there is prior agreement.

The table below sets out the production methods acceptable to CIRO, subject to prior agreement:

Production Method	Description
Native Format	Records are provided in the format used during regular business operations (e.g., Microsoft Word, Excel, PowerPoint, etc.).
Processed Data	ESI is converted into a static image. The most common formats are PDF file or TIFF images.
Hybrid Production	Hybrid production where data is produced as images, and the other file types produced in their native format. Spreadsheets should always be produced in native format.
Paper Copy Records	Paper records should be converted to image files prior to submission.

In situations where our systems cannot access or process submitted records, we will request that the data be reproduced in an alternative format compatible with our eDiscovery software.

4. Redactions

Where redactions are applied to records subject to a claim of privilege, they must be implemented in a manner that ensures the underlying content cannot be accessed by Enforcement Staff.

For redactions to be properly applied, the following common errors must be avoided:

Error Type	Description
Incomplete or Inconsistent Redactions	Only part of the sensitive information is redacted, leaving some exposed.
Improper Redactions Method	Using visual overlays without removing the underlying text, allowing redactions to be reversed.
Incorrect File Format	Saving the document in an editable format that allows redactions to be undone.

5. Handling Inadvertent Production of Privileged Documents

The producing party must take all necessary steps to ensure that any materials subject to privilege are not included in the records submitted in response to an RFI.

If privileged records are produced in error, the producing party must:

Step	Description
Notify Enforcement Staff	Immediately inform Enforcement Staff upon discovery of the inadvertent production.
Secure Records	Work with Enforcement Staff to secure the records and prevent further review.
Isolate Privileged Materials	Identify and isolate all privileged materials from the production set.
Rectify Production	Take appropriate steps to rectify the production, which may include re-producing the records and providing a privilege log, as agreed with Enforcement Staff.

6. Privilege

It is the responsibility of the producing party to ensure that any privileged material, including correspondence with legal counsel, is completely removed from the production provided in response to an RFI.

Failure to do so may result in waiver of privilege and any subsequent claim that Enforcement Staff improperly received, reviewed, or examined the documents. Further, the act of producing these documents to Staff may constitute waiver of any privilege applicable to these documents.

If privilege is claimed over any records, the producing party must identify the documents and communicate the basis for the claim to Enforcement Staff. A privilege log of the withheld documents should also be provided.

Instructions where records are subject to a claim of privilege:

Privileged Document Classification	Steps
Partial Privilege within a Record	Privileged content must be redacted; native files are not to be produced. A placeholder with the document ID must be provided.
Entirely Privileged Records Outside a Document Group	Exclude records that are entirely subject to privilege and are not part of a document group specified in the RFI.
Entirely Privileged Records Within a Document Group	Placeholder must indicate that the record is subject to a privilege claim and should be named using the document ID only; native files are not to be produced.
Privileged Parent Document	Each attachment must be produced separately and maintain its relationship to the privileged parent document via metadata (e.g., family or document ID reference).
Parent Document with Privileged Attachments	Original native file of the parent document should not be produced. A PDF should be provided in its place.

7. Privilege Log

The log should include the following information:

Field	Description
Document Date	Date the document was created or sent
Author(s)	Person(s) who created or wrote the document
Recipient(s)	All individuals who received the document (To, CC, BCC)
Document Type	Email, memo, letter, report, etc.
Privilege Type	Legal advice, work product, etc.
Description of Subject	Summary of the document’s content, without disclosing privileged info
Bates Number/Document ID	Unique identifier or Bates number (if applicable)
Custodian	Person or entity from whom the document was collected
Privilege Basis	The privilege claimed

PART III – ORGANIZATION AND DELIVERY OF ELECTRONIC STORED INFORMATION

8. Organization of Records Produced in Response to Request for Information

All files submitted in response to an RFI must follow a standardized structure. This includes using clearly labeled folders, providing a detailed cover letter, and identifying any cross-referenced documents. Please follow the steps outlined in the table below:

Step	Description
Cover Letter	Include RFI date and list of submitted items.
Folder Structure	Place documents in folders labeled by RFI item number.
ShareFile	Upload directly to the appropriate folders via ShareFile. Response Letter Item 1 Item 2 Item 3
Multi-Item Records	Note in the cover letter if a document relates to multiple items.

The producing party should maintain clear records of their document gathering and review process. Enforcement Staff may request an explanation of any matter relating to the compilation of the records or the records themselves.

9. Secure File Transmission

All records produced in response to an RFI must be transmitted securely via ShareFile.

PART IV – REQUIREMENTS FOR PRODUCING ELECTRONIC STORED INFORMATION

Enforcement Staff prefer the electronic records to be produced in their native file format. This ensures the integrity and full accessibility of the records, including all embedded metadata.

Native format may include:

The format in which records are ordinarily maintained in the usual course of business (e.g., Microsoft Word from a file server); and
The format generated by the originating system when exporting records (e.g., a PST container exported from Microsoft Outlook).

10. Key Requirements

The table below outlines the key requirements for the production of ESI:

Requirement	Description
File Format	Documents should be provided in native format when applicable. Original file types (e.g., .xlsx, .docx, .pst) must be preserved without conversion.
Metadata Preservation	All metadata must remain intact. Files must be contained in a single container, such as a ZIP or PST file prior to collection to prevent any alterations to the metadata.
File Integrity	All files must be scanned and free of viruses and malware to protect system security.
Parent and Attachment Document Groups	Parent-child relationships must be preserved during collection and production.
Duplicate Files	Duplicate documents should be retained.
Time Zones	Time zone settings must be applied prior to exporting email files.
Password Protected and Encrypted Files	Passwords must be provided in a separate document accompanying a Response Letter.

11. Acceptable File Formats

The eDiscovery system used by Enforcement Staff must be capable of reading and processing the documents produced.

Records maintained in a non-standard format should not be produced without prior approval from Enforcement Staff.

A complete list of acceptable file formats is set out in Appendix B.

Part V – INSTRUCTIONS FOR E-DISCOVERY PRODUCTIONS

This guidance is provided to assist producing parties in submitting records in a format compatible with Enforcement Staff’s eDiscovery software.

12. Metadata

When preparing a production in response to an RFI, all required metadata and document identifiers should be included to ensure proper ingestion, tracking, and review.

The producing party shall produce the metadata information with each production as described in Appendix A.

13. File Structure

The producing party shall produce the following sets of files for all produced documents:

Folder	Requirements
Load File	Each production must include a .dat metadata load file, which is a delimited text file format.
	First row of the file should contain a list of metadata columns.
	Each subsequent row contains the metadata for a single document.
	Each column of each row contains one metadata value, with values encapsulated by a special “quote” character and columns separated by a special “separator” character throughout.
	The load file should use a thorn (þ, ASCII character 231) as a quote character and the special, non-printing character DC4 (ASCII character 20) as a separator.
	First line must contain the column/field names.
	Fields Begin Bates, End Bates, and NativePath must be included.
	Each subsequent row must contain the metadata for one document.
	Every row must have the same number of columns/fields (empty values are acceptable).
	Text must be encoded in either ASCII, UTF-8, or UTF-16.
	Load File should be placed in the Data folder of the production in the root directory
Extracted Text and OCR Files (.txt files)	Single text file for each document containing all the document’s pages, in text.
	Pages separated by form feed character (decimal 12, hex 0x0C)
	Filenames should be of the form: <Bates num>.txt, where <Bates num> is the Bates number of the first page of the document
	Text and filenames must be encoded in UTF-8
	Files should be placed in the text/ subdirectory
Image Files	Filenames must be encoded in UTF-8
	Single 300 DPI, color, text searchable PDF file per document
	Single 300 DPI, color, text searchable PDF file per document
	Filenames should be of the form: <Bates num>.pdf, where <Bates num> is the BATES number of the first page of the document.
	Files should be placed in the images/ subdirectory
	PDFs shall include searchable text embedded in the document.
	No other information should be provided in image filenames, including confidentiality status.
Native Files	Filenames must be unique in the production, unless the content is identical. We recommend naming files by the Bates number of the first page of the associated document
	Files should be placed in the natives folder
	Filenames must be encoded in UTF-8
	Each filename, including extension, must correspond to the NativePath metadata field in its corresponding document’s row in the load file
	The filename must retain the file extension corresponding to the original native format; for example, an Excel 2003 spreadsheets extension must be .xls

14. Bates Numbering

The producing party should Bates number its production(s) as follows:

Type	Requirements
Document Images	Each page of a produced Document shall have a legible, unique page identifier (“Bates Number”) electronically “burned” onto the image at a location that does not unreasonably obliterate, conceal, or interfere with any information from the source document.
	Producing party must use a consistent prefix throughout the matter. Thus, once a party chooses a two-to-five letter prefix, e.g. ABCD, it shall not later produce a Document using a different prefix, e.g. EFGH.
	No other legend or stamp will be placed on the Document Image other than a confidentiality legend (where applicable), redactions, the Bates Number identified above. The confidentiality legend shall be “burned” onto each document’s image at a location that does not unreasonably obliterate or obscure any information from the source document.
	The Bates Numbers shall be enumerated as defined above in Key Terms
Native Format Documents	In order to preserve the integrity of Native Format Documents, no Bates Number, confidentiality legend or internal tracking number should be added to the content of the Native Document.
Sort Order	For Bates numbering, documents will be sorted by their original file path in ascending order, preserving family ordering.

For any additional questions regarding production requirements, the producing party must contact Enforcement Staff for clarification.

PART VI – PRODUCTION OF HARD COPY RECORDS

15. Scanning and Digitization of Paper Records

Each hard copy record must be electronically scanned and follow the specification below:

Specification	Requirement
PDF Files	Paper copy records must be scanned as multi-page black & white PDFs at 300 dpi. One PDF per document, not per page.
OCR and OCR Text File	Each scanned document must include a document-level OCR text file containing all extracted text.
Color	Scanned records should be in black & white unless color is essential to understand the content.
Oversize Original	If 8.5" x 11" size is insufficient, larger reproduction may be requested.
Unitization	Documents must remain intact; records must not be split or merged. Stapled or clipped pages are to be treated as a single document.
Compilations	Documents in compilations (e.g., binders) must be scanned separately. Original order and relationships must be preserved using metadata.

Following production, the original hard copy records shall be preserved according to applicable record retention requirements.

16. Producing Original Hard Copy Records

Where necessary, Enforcement Staff may require the production of original hard copy records. Such records must be produced in their original format without alteration. In these cases, Enforcement Staff will provide specific instructions regarding delivery.

APPENDIX A – METADATA

For each Document, the producing party must produce a line in the index file with the following fields, where available. The field naming conventions shall be the following:

Filed Name	Description	Data Type	Example
Begin Bates	Beginning Bates number of first page of a document	Text	ABCD000001
End Bates	Ending Bates number of last page of a document	Text	ABCD000003
Begin Family	Begin Bates of parent document of family of attachments	Text	ABCD000001
End Family	End Bates of last attachment of family	Text
Pages	Number of Bates stamped pages for the PDF image each document.	Number	3
NativePath	Relative file path of native record within production, including filename and extension of native file within the production. Only for documents produced in native format.	Text	.\VOL001\natives\ 001\ABCD000001. xlsx
Text Path	Relative file path of text record within production, including filename and extension of the text file within the production.	Text	.\VOL001\text\001\ ABCD000001.txt
Placeholder	If Bates stamped document is produced with a placeholder image (values: Y or N)	Text	Y
Redacted	If this document has redactions (values: Y or N)	Text	Y
All Custodians	For deduplicated documents, list of all custodians the duplicate copy was collected from.	Text
All Paths	For deduplicated documents, list of all file paths for duplicate copies.	Text
Author	Creator of document	Text	Jones
Bcc	Additional blind recipients of an email (Blind Carbon Copy)	Text	[email protected]
Cc	Additional recipients of email (Carbon Copy)	Text	[email protected]
Custodian	Name of person from whom documents were collected	Text	Jones
Date Created	Datetime document was created	Datetime	7/21/1969 2:56:00 AM
Date Modified	Datetime document was last modified	Datetime	7/21/1969 2:56:00 AM
Date Received	Datetime document was received	Datetime	7/21/1969 2:56:00 AM
Date Sent	Datetime email was sent	Datetime	7/21/1969 2:56:00 AM
File Type	The suffix at the end of the native filename indicating file type	Text	docx .pdf .xlsx
Filename	Original filename of native document, including extension	Text	Interesting spread sheet.xlsx
File Path	Original source file path, including location, folder name, filename, and extension	Text	media.zip//jones.pst//sent mail/444.eml//interesting_spreadsheet.xlsx
From	Sender	Text	[email protected]
In Reply To	Message id of email this email is in reply to	Text
Message Id	Unique message id from internet headers	Text
MD5 Hash	MD5 Hash value of Document	MD5 Hash
SHA1 Hash	SHA1 Hash value of document	SHA1 Hash
Subject	Subject line	Text	Check this out!
To	Recipient	Text	[email protected]

APPENDIX B – ACCEPTABLE FILE FORMATS

The following native file formats are compatible with CIRO’s eDiscovery software:

Email and Chat Formats	EML, EMLX
	Google Chat (Google Vault exports of mail-formatted chats and Hangouts JSON)
	iChat (DB)
	Microsoft Teams (HTML)
	Microsoft Teams (PST)
	Slack (as it was originally exported from Slack: a .zip file that includes files "users.json", "channels.json", and "integration_logs.json", plus any message .json files)
	Lotus Notes (NSF)
	MBox
	MSG
	OST
	PST
	OLM (Outlook for Mac)
	iOS WhatsApp (SQLite)
	Outlook Express databases
	TNEF (transport-neutral encapsulation format)
	Instant Bloomberg (IBXML) Package any associated attachments in the same container file as the IBXML file before upload.
	Bloomberg Messages (MSGXML) Package any associated attachments in the same container file as the MSGXML file before upload.
	RSMFv2 Must be compressed upon upload
	During upload and processing, CIRO's E-Discovery software ignores the outer EML file (which is useful only for backward compatibility reasons within the Relativity ecosystem), processes the JSON file(s) into a chat file(s), and extracts and links the attachment files. This means that RSMF data will now be properly represented as chats in CIRO's E-Discovery software.
Container and/or Compressed Files	7Zip (7Z) We do not currently support split zips created by WinZip
	AD1 (AccessData Images)
	E01, Ex01 (Encase)
	GZip, GZ
	Bzip
	Zlib-compressed data
	L01, Lx01 (Encase Logical Image)
	PST
	OLM (Outlook for Mac)
	RAR
	TAR, TGZ
	JAR
	WAR
	VeraCrypt/TrueCrypt
	ZIP
	AppleSingle
	CAB
	DBX
	MacBinary
	LEF (LiveNote Evidence File)
	Cellebrite UFDR Archive
	ACCDB, MDB (Microsoft Access database file)
	7Zip (7Z) We do not currently support split zips created by WinZip
Web Formats	HTML (HTM, HTML, XHTML, SHTML)
	MHTML, MHT
	SVG
Document Formats	Microsoft: Word, PowerPoint, Excel, OneNote (DOCX, DOC, DOCM, DOC95, RTF, PPT, PPS, PPTX, PPM, XLS, XLSX, XLT, XLS95, XLT5, XLSM, XLR, XLSB)
	OneNote 2010 files (ONE) does not support Sensitivity labels for Microsoft files and does not extract metadata about track changes or drafts in Word documents
	Spreadsheets
	Visio
	OpenOffice document formats
	PDF
	iWork (Pages, Numbers, Key)
	Note - iWork support is limited. We recommend converting Numbers documents to .xlsx or Google Sheets.
	WPD (WordPerfect)
	RTF (Rich text)
	All plain text files (TXT, CSV, XML, JSON, source code, etc.)
	QuattroPro (QPW, limited support)
	Lotus
	HWP
	Google Drive files
	XPS
	EPUB
	PTX
	XFA
Image Formats	GIF, TIF, TIFF, PNG, JPG, JPEG, HEIF, HEIC, PBM, TGA, JXR, DNG, WMF (Windows Metafile), EMF, BMP
Image Formats	When providing images that have texts, please include a text format for said images.
Medical Image Formats	DICOM (DCM)
Computer-Aided Design (CAD) Formats	DGN (V7, V8)
	DWG
	DXF
	Solidworks: . sldprtt , .slddrw, .sladasm
Audio and Video	MP3, AAC, WMA, WAV, FLAC, M4A, OGG, AIFF, OGA, AMR, VOX, MPG, MPEG, AVI, WMV, FLV, OGV, MOV, QT, M4V, MP4, WEBM, MPE, ASF, OPUS
Project Management Files	Microsoft Project (MPP)
	Microsoft Project Exchange (MPX)
	Microsoft Project Data Interchange Format (MSPDI)
	Primavera XML for P3 & P6
	Primavera P6 (XER)
	Primavera Self-Extracting Archive for P3 & P6 (PRX)
	Jira exports (Excel, Word, CSV, XML, HTML, PDF)
Geographic Information System (GIS) Files	KMZ/KML (GoogleKeyhole Markup Language)
	SHP/SHX (Esri Shapefile) There may be additional files that make up a Shapefile, such as .DBF and/or. PRJ, are identified as Database and Text types files, respectively. To capture the entirety of your Shapefiles, make sure you keep track of your GIS file collections and broaden any searches as needed.
	GPX (GPS eXchange Format)
	GEOJSON (Geographic JavaScript Object Notation)
	Unless the GIS file is a text-based file (ie. KML, GEOJSON), it will not be viewable in the review window. We recommend GIS files be opened in their intended application for proper viewing.
Other File Formats	PTX (electronic transcript)
	ICS (iCalendar)
	Apple PropertyList
	PostScript
	All plain text files (TXT, CSV, XML, source code, etc.)
	SQLite databases (SQLITE, SQLITE2)
	Disk Images (ISO, etc.)
	Common binary file formats (EXE, DLL, MSI, PGP, etc.)
	PCAP
	Zendesk exports
	DBF (database)
	eCTD (in zip or submitted as a folder)

APPENDIX C – KEY TERMS

Key Terms	Definition in E-Discovery Context
Document(s)/Records	ESI includes any data stored in a medium that can be accessed or converted into a reasonably usable form.
Electronic Records	Often referred to as ESI, are defined as data that is in electronic format. This includes a wide range of digital documents such as emails, presentations, databases, and more.
Hard Copy Records	Records stored in hard copy (e.g. paper, CD).
Document Group	A collection of related documents that are grouped together for review and production purposes. This grouping can be based on various criteria, such as file type, content, or relationships between documents.
Native File(s) or Native Format	ESI with an associated file structure must be produced in the format defined by the application in which it is normally created, viewed, or modified.
Metadata	Information associated with or embedded in a native file that is not part of its primary content, including system-generated metadata created during file creation, modification, transmission, deletion, or other user actions.
Load File	Electronic data file that identifies documents, defines which pages or files comprise each document, and includes associated metadata such as extracted text and coding information.
OCR	Optical character recognition, generating a text from an image of text using software.
Extracted Text	All text content extracted from a Native File.
Producing Party	Party producing documents in response to an RFI.
Bates Number	Identifier consists of a short two to eight letter prefix, associated with the producing party’s name, followed by 6 numbers (e.g. ABCD000001). The prefix should include only letters, dashes, or underscores. The prefix and number should not be separated by space. Each page in the production is assigned a unique, incremental Bates number. The prefix must be the same for all pages produced from the same producing party.
Request for Information	Formal inquiry issued by CIRO Enforcement Staff to a Dealer Member or a Regulated Person during the course of an investigation.

CONTACT INFORMATION

For any questions or comments about this Guide, please contact eDiscovery and Evidence Team at [email protected].

1As defined under section 1201 of the Investment Dealer and Partially Consolidated Rules and Rule 1A of the Mutual Fund Dealer Rules.