Asset Inventory for GDPR Article 32 — Evidence It in Jira

GDPR Art. 32 expects you to secure the devices that process personal data. Here's how to keep and evidence an asset inventory inside Jira.

GDPR Article 32 — "Security of processing" requires you to protect personal data with appropriate technical measures. You can't secure what you can't see: if a laptop or server processes personal data, you need to know it exists, where it is, and that someone has verified it. That's an asset inventory — and for teams on Atlassian, it belongs in Jira, not a spreadsheet.

This guide explains how asset inventory maps to Article 32, what evidence a data-protection auditor actually asks for, and how to produce it inside Jira Service Management Assets.

NOTE: Asset inventory is one security measure that supports Article 32. No tool "makes you GDPR compliant" — compliance is a program. This article is about producing one piece of that program well.

How asset inventory maps to Article 32

Article 32 doesn't list "keep an asset inventory" word-for-word, but it requires a level of security "appropriate to the risk," including the ability to ensure the ongoing confidentiality and integrity of processing systems. In practice, DPOs and auditors read that as:

• Know your processing assets — which devices and systems handle personal data.
• Control them — assigned owners, known locations, verified state.
• Demonstrate it — records that show the inventory is real and maintained, not a one-off list.

This is the same control formalized as ISO 27001 · A.5.9 (inventory of information and associated assets), which is why an ISO-style asset inventory doubles as GDPR Art. 32 evidence.

What auditors ask for

When a data-protection audit touches asset security, the questions are consistent:

• Is there a current inventory of assets that process personal data?
• Does each asset have an owner?
• Can you show the inventory is verified periodically — with dates and by whom?
• Can you export that record for the audit file?

A static spreadsheet fails the last two: it can't prove who checked what and when. (SOC 2 auditors probe the same gap even harder — see what SOC 2 asks for.)

Producing the evidence in Jira

If your CMDB already lives in Jira Service Management Assets, the inventory exists — what's usually missing is the verification record. Scannix adds that layer:

• Scope the audit to the assets that process personal data — by schema, object type, or Assets Query Language.
• Verify physically by scanning QR codes and barcodes with a free iPhone app (offline-ready, duplicate-protected).
• Record per-user timestamps — every verification is attributed and dated.
• Export to CSV to attach directly to your Art. 32 evidence file.

Verified assets with verifier and timestamp, ready to export

Because Scannix is built on Atlassian Forge, your asset data stays in your Atlassian site — relevant when Article 32 also asks where processing data resides.

For the full walk-through of setting up an audit, see the step-by-step guide to physical asset audits in Jira.

Make it repeatable

Article 32 expects ongoing security, not a snapshot. With Jira Automation you can schedule asset verification on a fixed cadence (e.g. quarterly), so the inventory stays current and each cycle leaves its own timestamped record — exactly the "maintained over time" signal auditors look for.

FAQ

Turn your Jira CMDB into Art. 32 evidence

Stop maintaining a separate spreadsheet you can't defend in an audit. Verify the assets that process personal data where they already live — in Jira — and export the timestamped, per-user record auditors ask for.

👉 See how Scannix produces asset-audit evidence