Workspaces, teams and projects

An enterprise estate is almost never one thing. It is a set of legal entities, business units, regulatory regimes and environments that happen to share a logo. AutoPQC models that shape directly rather than flattening it into a single list of assets. This page describes the containers, what crosses a boundary and what does not, and how a finding in one corner of the estate becomes a number a board can read.

#Three containers, one estate

There are three levels. Each exists for a specific reason, and each one you add costs something in coordination, so the correct number is the smallest number that reflects how your organisation is actually governed.

Organisation

The contracting entity. One organisation per customer. It owns the commercial relationship, the identity configuration, and the list of people who may sign in at all. Billing, single sign-on and the member directory live here and nowhere else.

Workspace

A partition of the estate with its own inventory, its own exposure score and its own membership. A workspace is the unit of isolation. If two parts of your business must not see each other's cryptographic inventory, they belong in different workspaces.

Project

A scoped unit of work inside a workspace — a discovery sweep, a remediation wave, a migration programme for one payment rail. Projects group runs and findings so that progress is measurable against something narrower than the whole estate.

The distinction that matters most: a workspace is a security boundary, a project is a reporting boundary. Moving an asset between projects changes how it is counted. Moving it between workspaces changes who can see it at all.

#Partitioning an estate

Most organisations get this right on the second attempt, because the first attempt mirrors the org chart and the org chart changes. Partition on the lines that are slow to move.

• Legal entity. A subsidiary with its own regulator, its own data-residency obligation or its own auditor should be its own workspace. This is the strongest reason to split.
• Regulatory regime. An estate subject to EU DORA obligations and an estate that is not will produce different evidence packs and different remediation deadlines. Splitting them keeps each pack clean.
• Environment. Production, pre-production and laboratory estates have wildly different acceptable-risk profiles. A self-signed RSA-2048 certificate in a test harness is not the same finding as the same certificate terminating customer traffic.
• Acquisition boundary. Newly acquired infrastructure usually has an unknown baseline and a separate remediation owner. Keep it separate until it is understood, then merge.
• Nothing else. Do not create a workspace per team, per application or per quarter. Use projects for that. Workspace sprawl fragments your inventory and makes the aggregate score meaningless.

#What is shared, and what is isolated

The rule of thumb: identity and method are shared, data is not. Everyone in an organisation authenticates the same way and is scored against the same published method. What they can read depends entirely on workspace membership.

Because the method is shared, two workspaces are comparable. That is the point. A score of 62 in one subsidiary and 81 in another means something only if both were graded by the same rubric — see How the exposure score is built and How the method is versioned.

#How findings and scores roll up

Scoring happens at the asset level and aggregates upward. An asset carries its own severity. A project's score is the aggregate of its assets. A workspace's score is the aggregate of its projects. An organisation-level view aggregates workspaces.

Aggregation is not an average of averages. Each level recomputes from the underlying asset set so that a workspace holding four assets does not carry the same weight as one holding four thousand. In our pilot estate, 42 cryptographic assets produced an aggregate risk score of 75 / 100, with 36 of those assets classified vulnerable. The arithmetic that turns those counts into that number is documented in full under The inputs, the weights, and where they come from.

• A finding accepted in one workspace does not silently suppress the equivalent finding elsewhere. Each workspace owns its own risk decisions.
• An asset that genuinely appears in two workspaces (a shared HSM, a shared internal CA) is counted in both, and that is intentional. Two teams both carry the risk.
• Rolling up never invents a severity. If a project contains no scored assets it contributes nothing rather than contributing a neutral value.

#Membership, lifecycle and archival

People are added at the organisation level and then granted a role in each workspace they need. Removing someone from the organisation removes every workspace grant they hold, in one action. That is the property you want during offboarding.

1. 1

   Create the workspace

   Name it after the thing it contains, not the team that owns it today. Set its regulatory context and data-residency expectation at creation, because both influence what evidence we retain.

2. 2

   Grant roles

   Assign the smallest role that lets each person do their job. The role set and what each one can do is in Roles and permissions.

3. 3

   Open a project and scope it

   Define the address ranges, repositories, hosts and certificate stores in scope. What discovery can and cannot reach is covered in What discovery will not do.

4. 4

   Archive rather than delete

   Closing a project preserves its findings and its evidence trail so that a later audit can reconstruct what was known and when. Deletion is a separate, deliberate action.

Retention and deletion of archived material follow the rules in Retention and deletion, not a per-workspace setting. There is one policy and it applies everywhere.