> ## Documentation Index > Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt > Use this file to discover all available pages before exploring further. # Key concepts > The building blocks of Pharus: workspaces, product families, SBOMs, matches, incidents, awareness, clocks, routing and records. This page explains the words Pharus uses and how the pieces fit together. Each section links to the page that covers it in depth. Short definitions of the regulatory terms are in the [glossary](/help/glossary). ## Workspace and members A **workspace** is one company in Pharus. The app calls it a company: you switch between your companies in the sidebar, and **Settings → Company** holds its details. Every record in Pharus belongs to exactly one workspace, and nothing is shared between them. One person can be a member of several workspaces. Each **member** has one role: **owner**, **admin** or **member**. Owners handle billing and can close the workspace; owners and admins manage settings, people and the decisions that need a second level of authority; every member can do the day-to-day work. See [members and roles](/workspace/members-and-roles). ## Product family A **product family** is a group of products that share their software, such as a gateway sold in three hardware variants with the same firmware. SBOMs, API tokens, support periods and the Annex VII technical documentation belong to a product family. Plans are priced and limited per family. See [product families](/monitoring/product-families). ## SBOMs, components and matches An **SBOM** (software bill of materials) lists the components in a build of your product. Pharus reads CycloneDX and SPDX SBOMs in JSON, from your pipeline, from Dependency-Track or from an upload. Each component is identified by its **purl** (package URL). Pharus matches every component against OSV.dev. A **match** says that a known vulnerability affects a component in one of your product families. Pharus also checks each vulnerability against CISA's Known Exploited Vulnerabilities catalog (KEV) and ENISA's EU Vulnerability Database (EUVD): a match on a vulnerability known to be exploited is the one that can start the CRA clock. For each match you record a **VEX status**: affected, not affected (with a justification), fixed, or under investigation. VEX statuses feed your [advisories](/disclosure/advisories). See [vulnerabilities](/monitoring/vulnerabilities). ## Incident An **incident** is one reportable event, with a reference such as `INC-0042`. Article 14 of the CRA knows two kinds: * An **actively exploited vulnerability** in your product (Art. 14(1)). * A **severe incident** that affects the security of your product, such as a compromised build or update server (Art. 14(3)). A new exact match on an exploited vulnerability opens an incident by itself. You can also declare one by hand, or from a report in the disclosure inbox. See [incidents](/incidents/overview). ## Awareness and clocks The **awareness time** is when you became aware of the incident. For an incident Pharus opened from a match, it is the time Pharus first saw the match as exploited. Every CRA deadline counts from it, so it is recorded once and corrected only by an owner or admin, with a reason, in the audit trail. The **clocks** are the CRA deadlines that run from awareness: | Report | Due | | - | - | | Early warning | 24 hours after awareness | | Vulnerability or incident notification | 72 hours after awareness | | Final report, actively exploited vulnerability | 14 days after a corrective or mitigating measure is available | | Final report, severe incident | One month after the notification | See [clocks](/incidents/clocks). ## Determination and decision record The **determination** is your company's answer to the question an incident turns on: is it reportable under CRA Art. 14? For a vulnerability, was it actively exploited in your product; for an incident, is it severe? On Core and Plus, the **decision record** keeps the rationale, the evidence and the approvals for each answer on the incident's **Determination** tab, in entries that can't be changed afterwards. The awareness time is kept apart from it, on the incident's Overview tab. See [decision record](/incidents/decision-record). ## Routing, the SRP and CSIRTs CRA reports go through ENISA's **Single Reporting Platform** (SRP) to a **coordinating CSIRT**: the computer security incident response team of one EU member state. Article 14(7) decides which one: the member state of your main establishment in the EU, if you have one. Otherwise the first link in a cascade that is in an EU member state: your authorised representative, then your importer, then your distributor, then the member state with the most users. The CRA is not yet part of the EEA Agreement, so a Norwegian manufacturer follows the cascade too. Pharus works out the route and prepares an **SRP paste pack**: the fields of the SRP form, in English, filled in where Pharus has the answer and ready to paste. See [routing](/incidents/routing) and [SRP paste pack](/incidents/srp-pack). ## Regimes A **regime** is one set of reporting rules that may apply to the same incident. Next to the CRA, Pharus assesses GDPR (Datatilsynet), digitalsikkerhetsloven (NSM) and, for financial entities, DORA (Finanstilsynet), each with its own deadlines. For a company established in Norway, NIS2 is shown as tracked: it is not yet Norwegian law. See [Norwegian notices](/incidents/norwegian-notices) and [DORA](/incidents/dora). ## Disclosure reports and advisories A **disclosure report** is a vulnerability report from someone outside your company, sent through your public disclosure page or by email. It lands in the **disclosure inbox**, where you reply, triage and, if needed, declare an incident from it. See [disclosure page](/disclosure/disclosure-page) and [inbox](/disclosure/inbox). An **advisory** tells your customers which of your products a vulnerability affects and what to do. Pharus publishes advisories as CSAF 2.0 documents with VEX statuses, on a public page and in a machine-readable feed. See [advisories](/disclosure/advisories). ## Audit trail The **audit trail** logs every determination, approval, filing and setting change, with who did it and when. Entries can't be edited or deleted. See [audit trail](/reports/audit-trail). ## Related Set up a workspace and match your first SBOM. Short definitions of CRA and reporting terms. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.