What happens to unclassified work items when you set a default classification level in a Jira space?

Hello @Sveinung Solhaug , the thread has two opposite answers, so here is what Atlassian's documentation says, and then the rollout order that makes the answer safe either way.

@Gabriela - LeanZero has it right: a default is not forward-only. Atlassian's definition of a default classification level is that it "applies to new or unclassified content, such as pages and work items, until manually updated by a user or a classification rule" (What is a default classification level), and the hierarchy page says a space or project level "applies to new and existing content objects" (What is data classification). So once you set a project default, every currently unclassified work item in that project resolves to it. @John Funk  "new items only" is how most of us would expect it to work, but it is not how it is documented. @Nikola Perisic , work item security levels are the other family entirely, they gate who can see an item, not what class it carries.

The nuance that matters for your estate: it is inheritance, not a sweep. The default is a fallback layer, resolved when the item's classification is read. Three consequences:

1. Items that already carry a manually set level keep it, the default never overrides an explicit classification.
2. Nothing is written onto each item; if you later clear the project default, those items go back to unclassified rather than staying stamped.
3. There is no audit trail per item of "was classified by default," because nothing happened per item.

So "existing unclassified items get swept" is true as a visible effect and false as a data change. That distinction is what lets you do this safely.

The safe order of operations for a project that already holds unclassified content:

1. Set the project default to the least sensitive level you use ("Internal," not "Confidential"). A default is a baseline, and Atlassian's own guidance is that baselines should be the lowest level, because everything unclassified inherits it instantly.
2. Before you set it, check your data security policies. Any policy keyed on that level (export blocked, public links blocked, app access blocked) starts applying to every previously unclassified item in the project the moment the default lands. That is the only thing about this that can surprise users on day one.
3. Classify the sensitive items explicitly (manually, or with classification rules where your org has them) so they are pinned above the baseline and immune to later default changes.
4. Tell the project that the badge appearing on old items is the baseline, not a decision someone made about each one.

One side note for planning: the equivalent "default for all Confluence products" control is listed as coming soon in Atlassian's cloud roundup, while the per-project and organisation-wide defaults already exist, so if you are rolling this out across both products, Jira is the one you can finish first.

Hi Sveinung - Welcome to the Atlassian Community!

Guard and Work Item Security are different things. Work Item Security comes built into your Jira license and works to restrict access to work items based on parameters you set. Guard connects to identify providers to do things like SSO and authentication assistance. 

When you create a security level, you can decide if it will be the default - but it will not apply to existing work items - only all new work items. 

Hi Sveinung,

Work item security and data classification are separate features, and the security doc frames itself against permissions rather than against classification: "work item security schemes let you control who can see specific work items within that space". That route governs who can open an item and will not set a classification level on anything.

On the classification side, I don't think a default gives you the split you're after, because Atlassian generally treats new and unclassified as a single bucket rather than as two separate ones: "A default classification level applies to new or unclassified content, such as pages and work items, until manually updated by a user or a classification rule." The organization-level page puts it identically, as "automatically applied to all new or unclassified content across your organization".

So a default set to catch your new work items would usually sweep up every existing item that carries no classification today, which is the outcome you said you wanted to avoid.

I don't think classification rules rescue it either, since they key off what sits inside the content rather than how new an item happens to be: "When Guard detects matching data in a content object, such as a Confluence blog post or a Jira work item, it applies the relevant classification rule."

How many unclassified items would a default actually catch in your instance?

Welcome @Sveinung Solhaug 

That is work item security. You need to create a new security level for that work item security scheme. Security level field also needs to be added to the Create screen as well.

https://support.atlassian.com/jira-cloud-administration/docs/what-are-work-item-security-schemes/