Introduction to GRC: from requirements to operational readiness with Pulsar GRC and Crewshift

Hypothetical examples. The scenarios and outcomes explain a workflow; they are not a customer audit report or a guaranteed result. Check the current offer for feature scope, CrewShift workflows and service terms.

ISO 9001:2026 update (29 September 2026). The final edition was published on 16 September 2026. Use a lawful copy of the applicable version and review effects on requirements, risks and opportunities, controls and evidence. Historical 2015 references, including IATF references, retain their context; do not automatically replace clause numbers. Agree the certification schedule with your certification body. Update guide · ISO source.

GRC starts with responsibility, not with software

GRC, or Governance, Risk & Compliance, brings together three areas that should work as one:

• Governance - who makes decisions, who owns the process, and how the Organization operates.
• Risk - which events could affect goals, quality, compliance, or operational continuity.
• Compliance - how the Organization proves alignment with laws, standards, procedures, customer requirements, and internal policies.

In many companies these areas exist, but they are fragmented. Documents sit in one place, risks in spreadsheets, CAPA in email threads, evidence in folders, and training records in a separate system or files. GRC then becomes last-minute audit preparation instead of a steady operating rhythm.

The value of the Brillnet platform is to structure that flow. Pulsar GRC organizes requirements, controls, risks, audits, CAPA, and evidence. Crewshift handles the people-side work: training, acknowledgements, competencies, and scenario exercises. Both applications use the same Brillnet compliance engine, but they solve different problems.

What does GRC mean in daily work?

For a Quality/Compliance Manager, GRC is not an abstract model. It is a way to answer practical questions:

• which requirements apply to our Organization,
• which source documents are current,
• which controls prove that requirements are met,
• where we have a gap and who owns its closure,
• whether CAPA has an owner, deadline, evidence, and proof that the action worked,
• whether the team understands what changed in a procedure,
• whether a consistent evidence package can be shown before an audit.

Pulsar GRC turns these questions into connected objects: document, requirement, control, evidence, risk, CAPA, owner, and decision. As a result, compliance status is not a statement from the last meeting. It is the outcome of work on your Organization’s data.

What makes the Brillnet-Pulsar-Crewshift model different?

Pulsar GRC works on your Organization’s documents stored in your isolated Data Area. Your Organization must have the source documents it wants to comply with: standards, procedures, legal requirements, customer requirements, or internal policies.

Brillnet does not sell standards content, normative texts, or ready-made requirement catalogues. The platform helps organize and map documents supplied by the Organization. On that basis, Pulsar GRC supports the creation of the Coverage Graph and Gap Analysis.

In practice, the flow is straightforward:

1. The Quality/Compliance Manager imports source documents into the isolated Data Area.
2. Pulsar GRC helps map requirements to controls, evidence, owners, and risks.
3. The Coverage Graph shows what is already supported by evidence and what still needs work.
4. Gap Analysis identifies missing elements, priorities, and dependencies.
5. CAPA takes the team from a detected gap to closure.
6. Crewshift handles actions that require work with people: training, acknowledgements, competencies, and scenario exercises.

AI acts as controlled process support. It helps organize, connect, and analyze data, but it does not replace the Organization’s decisions. Acceptance, priority, and closure decisions always remain with your Team and your Organization.

Example: manufacturing, quality, and audits

In manufacturing, GRC often meets ISO 9001, BRCGS, IFS Food, IATF 16949, customer-specific requirements, and local procedures. The issue is rarely that the Organization has no documents. The real issue is whether documents, controls, risks, and evidence form one coherent picture.

Pulsar GRC helps structure that layer:

• a requirement from a standard or customer requirement connects to a specific control,
• the control has evidence, an owner, and decision history,
• a gap moves into Gap Analysis and then into CAPA,
• risk shows operational impact and priority,
• an evidence package can be prepared without manually searching several places.

When an analysis result requires action with people, Crewshift carries the next stage. That may be training on a new procedure, acknowledgement of an instruction, a competency record, or a scenario exercise before an audit. Compliance then does not stop at the document. It reaches the team that needs to understand and perform the change.

What problems does mature GRC solve?

GRC creates the most value when the Organization stops working reactively. Instead of assembling evidence during the final week before an audit, the team sees readiness continuously.

Mature GRC helps reduce:

• repeated questions across different audits,
• manual evidence collection from email and folders,
• unclear CAPA ownership,
• requirements that are “met” only in a spreadsheet,
• missing links between a gap, risk, evidence, and training,
• knowledge loss when the process owner changes.

Useful organisational knowledge comes from identified sources, versioned decisions and evidence that a reviewer can follow. A later review may reuse that history, but its owner must check which facts remain current. If AI prepares a draft, retain the sources actually used and examine each proposed conclusion. This is a recommended working method; storing records does not by itself guarantee better analysis or automatic learning about the organisation.

How to start without adding chaos

You do not need to start with a full transformation program. It is better to choose one process where fragmented information already creates real cost for the team:

1. Choose a compliance area - a customer audit, BRCGS, ISO 9001, CAPA, risk register, or supplier process.
2. Collect source documents - standards, procedures, customer requirements, instructions, and evidence that already exist in the Organization.
3. Map requirements in Pulsar GRC - connect requirements with controls, evidence, owners, risks, and CAPA.
4. Move people-side actions to Crewshift - training, acknowledgements, competencies, and scenario exercises should live in the application designed for that area.
5. Work from gaps, not assumptions - use the Coverage Graph and Gap Analysis as the basis for team decisions.

Summary

GRC is valuable when it helps the Organization work with more predictability, speed, and control over evidence. Pulsar GRC structures the compliance, risk, audit, CAPA, and evidence layer. Crewshift helps bring required changes to people through training, acknowledgements, competencies, and exercises.

Together they create a practical operating model: requirement → control → evidence → risk → CAPA → team action. That flow turns GRC from an audit project into a daily system of operational readiness.

---

Want to see how this flow would work in your Organization? Ask for Pulsar GRC access and describe the process you want to structure.

Decide what belongs in the first GRC scope

The operating methods below are our recommendations, not a new set of regulatory obligations. Begin with a process whose failure has a recognisable business effect. Supplier approval, customer security questionnaires and corrective actions are useful candidates because they combine a requirement, a decision and evidence. Avoid choosing the entire organisation as the first scope. It makes the backlog large before the team has tested how the records will be maintained.

Write the boundary in one sentence: “This pilot covers approval and reassessment of packaging suppliers for Plant A.” List what is outside that boundary, such as transport providers or another production location, and assign a date for considering it. The boundary keeps an unrelated request from becoming an unplanned implementation project. It also prevents the pilot’s results from being described as organisation-wide compliance.

Identify the decision-maker, process owner and evidence contributors. These may be different people. The decision-maker accepts a supplier or residual risk. The process owner maintains the workflow. Contributors provide assessments, certificates or testing results. One person can hold several roles in a small organisation, but the roles should still be explicit. Otherwise a missing approval can be mistaken for a missing file and assigned to the wrong person.

Work through one requirement in full

Consider a hypothetical customer requirement to reassess an approved supplier after a manufacturing-site change. The source is a customer specification with a version and effective date. The risk is that an unchanged approval may conceal a different production process. The control is a change notification followed by a reassessment decision. Evidence includes the notification, assessment and approval or restriction.

When the location changes, open the review. The owner checks which orders and products are affected, obtains the relevant evidence and records a decision. If the assessment is incomplete, the organisation may impose a justified temporary restriction. That restriction needs an owner and review date. Keeping an issue open with a documented control is more honest than marking it complete because a deadline is approaching.

The same case can then produce a people-related action. Buyers may need to recognise the notification and route it correctly. Acknowledgement of a revised instruction shows that it reached them, while a short exercise tests whether they can apply it. The exercise should use a changed location, not repeat the instruction verbatim. If participants route the case incorrectly, review the instruction and workflow before prescribing more training.

Distinguish a control from a task

A task has an end: obtain a document, review a contract or revise an instruction. A control operates repeatedly: every relevant change triggers an assessment, or every defined period triggers an access review. Closing the implementation task does not prove that the recurring control will continue. Record the trigger, responsible role, expected output and exception handling for the continuing activity.

This distinction matters when a temporary project hands over to operations. In the supplier example, creating the reassessment form is an implementation task. Detecting and reviewing future changes is the operating control. At handover, confirm where notifications arrive, who monitors them during absences and how an unresolved case escalates. A well-designed form is useful only if the next change reaches the person who uses it.

Use a small, honest readiness scorecard

Start with counts that have defined denominators. For example: approved requirements with a named owner out of all requirements in the pilot; scheduled reviews completed out of reviews due; closed CAPAs with effectiveness evidence out of closed CAPAs sampled. Keep “not applicable” separate and retain the justification. Otherwise a high completion percentage may result from removing difficult items rather than completing them.

A green indicator should mean that the agreed evidence criteria were met for the stated scope. It does not mean that a regulator or certification body has endorsed the process. Show rejected evidence and unresolved exceptions beside the percentage. An apparently weaker dashboard can be more useful if it exposes what the owner still needs to decide.

Review the scorecard on a practical cadence linked to the process. A low-frequency supplier process may need event-driven reviews and a monthly backlog meeting. An active corrective-action portfolio may need a weekly review. The meeting should produce decisions: change priority, remove an obstacle, accept a justified delay or reopen ineffective work. Repeating status aloud adds little value.

Know when to extend the pilot

Extend the method when owners can maintain records during normal work, another colleague can follow the evidence trail and the team can deal with an exception without creating a parallel spreadsheet. Check this with real cases or clearly labelled demonstration data. Do not use invented improvements as a business case.

The first month may reveal that the problem is an unclear procedure rather than missing software. Correct that procedure. GRC tools can organise a sound workflow and expose an unsound one; they cannot create authority, expertise or evidence that the organisation has not supplied. A useful pilot ends with both a working case and a clear account of the work that remains.