Exporting ISMS data: How to test your future exit

An export is useful only if someone can continue working with it outside the original software. A ZIP file alone does not prove that. What matters is whether risks, measures, document versions and evidence still fit together after download.

Test data portability during your ISMS pilot project. You can then identify missing data or unusable formats before making a long-term decision.

Start with an everyday question

Choose a complete evidence chain: a requirement, its assigned measure, the owner and evidence of implementation. Add an older piece of evidence and a revised assessment. Download this sample into a separate review area.

Another person should then be able to answer: which measure applied at that time? Who approved it? Which evidence belonged to it? If answering still requires an active account with the old provider, portability has not yet succeeded for this purpose.

An actual change also requires migration into the target system. Our guide to switching ISMS software while retaining evidence history explains how to preserve earlier decisions.

Include these components in the test

Not every export needs every conceivable detail. Write down which information you need for continued operation, retention and switching providers. Separate essential data from convenience features that may work differently in the new system.

Do more than count files

Comparing counts is a good start, but not a complete check. Two attachments can share a filename. One measure can appear in several programmes. A CSV export may truncate long text or represent relationships only as internal identifiers.

Deliberately choose edge cases: accented characters, several owners, large attachments, archived records and a measure linked to several controls. For each, document the starting state, export result and any limitation. Our Excel migration guide explains why stable identifiers and mappings matter before migration.

Example: The file is there, but its context is missing

Fictional case: An organisation exports a recovery test as a PDF. The test itself is readable. The spreadsheet export, however, lacks the relationship to the measure and the system environment at the time.

The team does not simply add an arbitrary link. It checks whether a relationship table or supplementary report is available and records how to preserve the mapping reliably. If no dependable solution exists, that limitation becomes part of the purchase decision.

The issue is not the volume of exported data. It is the lost answer to the review question.

How Space export works in Kopexa

The Kopexa data export documentation describes a bundled ZIP export of a Space’s data and files. Find it under Settings, Space settings, Data export. Generation runs in the background; after successful completion, you can download the archive.

Test your specific use case here too. A general export function does not automatically mean another product can import every relationship and version unchanged. Those are two separate tests.

Kopexa links evidence to measures, and measures are mapped to controls. That relationship is particularly important for your export test. Our article on reusing evidence across several audits explains why the same file may matter in different assessment contexts.

Acceptance and secure storage

Finally, record which export and data state were tested, which cases passed and which gaps remain. Name someone to accept the result from a business perspective.

The archive may contain confidential security information. Define access, storage and deletion of the test copy. A downloaded export is also not automatically a tested recovery procedure.

For software selection, a successful trial is worth more than the mere presence of an export button. Bring your test case into the guided trial.