There is a specific kind of work that CRA compliance creates, and almost nobody budgets for it. Call it the transcription tax. The regulation asks a manufacturer to produce evidence that certain activities happened, and in most engineering organisations those activities did happen and were recorded carefully, in Jira tickets and Confluence pages. Then compliance tooling asks for the same facts again, in its own document format, in its own system. So the team writes the record twice, and the second copy begins going stale the moment it is saved.
We shipped an Atlassian connector to remove that second copy. This post covers why the problem is structural rather than a matter of discipline, what the connector does, and the two design decisions that matter most, which are both about what it deliberately refuses to do.
Annex VII asks for records of activity
It helps to be precise about what the technical file actually demands, because the word "documentation" invites the wrong mental model.
Annex VII(2) requires the cybersecurity risk assessment, which is a record of an analysis someone performed against a specific architecture at a specific time. Annex VII(3) requires the software bill of materials and component documentation. Annex VII(4) to (6) require reports of the tests carried out to verify conformity with the essential requirements, together with a reference to the coordinated vulnerability disclosure policy. Underneath those sit the Annex I Part II vulnerability handling requirements, which oblige the manufacturer to address vulnerabilities without delay, to test and review the product's security regularly, and to distribute security updates.
Read the list back and notice what kind of object each item is. A threat model. A test report. A record that a vulnerability was found, assessed, fixed, reviewed and released. These are not statements of intent that a policy document can satisfy. They are traces of work, and a market surveillance authority reading the file is looking for exactly that, evidence that the process ran rather than evidence that the process was described.
Which is the interesting part, because the traces already exist. The threat model is a Confluence page with a revision history and named authors. The vulnerability is a Jira issue with a severity, a linked fix commit, a reviewer and a resolution date. The penetration test findings are tickets that were opened and closed. An engineering organisation running a normal secure development lifecycle is producing Annex VII evidence continuously as a byproduct of working. It just does not look like a technical file.
Why the transcribed copy decays
The standard response is to export, summarise and paste into whatever the compliance system wants. That works once. It does not survive contact with a release cadence.
We covered the update duties in an earlier post. Article 31(2) requires the technical documentation to be continuously updated at least during the support period, Article 13(3) requires the risk assessment to be updated as appropriate, and Article 13(13) keeps the whole file inspectable for at least ten years. Meanwhile the underlying tickets and pages keep moving. Someone reopens the issue. Someone revises the threat model after an architecture review. The compliance copy does not know any of this happened, so it silently diverges, and the divergence is invisible until an authority compares the file against the shipping product.
Manual transcription also has a quieter failure. It is nobody's job. It sits between the engineer who did the work and the compliance owner who needs the record, and work in that gap gets done late, in a rush, before an audit, by whoever is available. That is the worst possible time to be reconstructing what happened eighteen months ago.
What the connector does
An admin connects the company's Atlassian site once, under Settings, Integrations, Jira and Confluence. It takes three fields, the site URL, an account email and an Atlassian API token created at id.atlassian.com under Security, API tokens. We recommend a dedicated read-only service account rather than a personal token, for the usual reasons about people leaving and permissions being broader than the task needs. The token is verified against the site when you save it, stored encrypted, and never shown again.
After that, the work is per product. Each product's Assess tab gains an import section under "Analyze a document", where you supply a Jira JQL query, a Confluence CQL query, or both. The queries are the interesting part of the design, because they let each team express its own convention rather than forcing a shared one. A team that labels security work gets the tickets by label. A team that keeps product documentation in a dedicated space gets the pages by space. A team that tracks penetration test findings in their own project gets those. Nobody has to reorganise Jira to satisfy a compliance tool.
Running the import pulls the matching issues and pages, converts each into a text document and pushes it through the same analysis and review pipeline that an uploaded PDF goes through. The analysis reads the content and proposes which Annex I requirements and which clause artifacts the document supports. Imports are capped at a dozen items per run, which is deliberate. The bottleneck is human review, not fetching, and a run that dumps two hundred candidate documents into a review queue produces a queue nobody works through.
Re-running an import skips anything that has not changed at the source since it was last pulled, so the second run is cheap, creates no duplicates and spends nothing on analysis. Ticking "Re-check nightly for changed sources" turns that into an automatic nightly sync for the product, which picks up new and modified items matching the saved queries.
Changed sources are handled by state rather than overwritten. If the stored document is still a draft, the new version replaces it. If it was already confirmed as evidence, the edit in Jira produces a new draft alongside it and leaves the confirmed record untouched. Confirmed evidence is something a reviewer put their name to, and a ticket edit three months later should surface as a thing to look at, not silently rewrite what the file already asserts.
The two refusals
Two things the connector will not do define it more than the feature list does.
It never turns an import into confirmed evidence by itself. Every imported item arrives as a draft with proposed control mappings, and a person has to review and confirm those mappings before anything becomes part of the assessment. This holds for the nightly sync too, which can fill a review queue but can never close a requirement. The reason is not caution for its own sake. The technical file is a document the manufacturer signs and stands behind, and the moment a machine can mark an Annex I requirement satisfied without a human looking, the file records what an automated matcher believed rather than what the manufacturer asserts. The connector's job is to eliminate retyping, not to eliminate the judgment.
It also refuses to fetch from anywhere except Atlassian Cloud. The site URL is constrained to the atlassian.net domain, and redirects are refused rather than followed. Any feature that fetches a user-supplied URL from the server is a server-side request forgery risk, and a connector that accepted an arbitrary host would be a general-purpose fetch tool that happens to authenticate with your credentials. Locking the host and refusing redirects costs a self-hosted Data Center customer the feature for now, which we think is the right trade until it can be supported without loosening the guard.
What it means for the file
The change is small to describe and large in practice. The record of the work stops being something a compliance owner reconstructs and becomes something the platform reads from where it already lives. Divergence stops being invisible, because a nightly sync surfaces the change as a draft rather than letting the copy quietly age. And the engineer who fixed the vulnerability does not have to write a second account of having fixed it.
What it does not read
Worth being plain about the boundaries, because they change how you write your queries.
The connector reads text. A Jira issue arrives as its summary, type, status, resolution, priority, labels, components, fix versions, dates and description. A Confluence page arrives as its title and body. It does not fetch attachments, and it does not fetch Jira comments. That last one matters more than it sounds, because plenty of teams keep the substance of a security discussion in the comment thread and leave the description as one line. It also means a Confluence page whose real content is an attached PDF will import as a nearly empty document, which is worth checking before you rely on a space full of them.
Long documents are truncated at twenty thousand characters. Queries are capped at five hundred characters, so a very elaborate JQL expression may need narrowing into two runs. Connecting the site and running imports are both admin-only actions, and the nightly sync re-checks entitlement each night, so a workspace that drops off Enterprise goes dormant rather than failing loudly.
None of this makes a technical file complete. Queries only find what the team actually recorded, and a gap in Jira is a gap in the evidence base, which the connector will faithfully reproduce. What it does is remove the excuse that the evidence was too scattered to assemble. For most manufacturers the evidence was never scattered. It was in the issue tracker, in the same place it has always been.
The connector is available on Enterprise workspaces. The products workspace documentation covers the setup in full, and the technical documentation post covers what the file has to contain before you start feeding it.