Summary

An organization is the tenant. Every record you see belongs to exactly one organization, and nothing is shared across organizations except the control catalog.
Two customer segments, Compliance and Privacy, decide which modules appear in the sidebar. Most modules are shared by both.
Most records are authored by you. A specific set is derived by Noru (automatic evidence, register evidence, module links, generated risks, imported policies) and can be recomputed. The tables below say which is which and where each change is logged.

An organization is the unit of isolation. Members belong to an organization with one role each (see Roles and permissions), and every query Noru runs on your behalf is scoped to the organization you are signed in to. There is no cross-organization view for customers.

Each organization carries one or more segments. An organization with both segments sees the union of both module sets.

Segment	Sidebar modules it unlocks
Privacy	Privacy plan; Privacy with Overview, Inbox, Data map, Records, Assessments, Monitoring
Compliance	Overview, Controls, Assets, Policies (under Evidence), Security, Questionnaires (under Vendors), Personnel, Audit, Trust Center
Both	Evidence Vault, Risk Management, Vendors (Overview, Register, Reports), Data Sources

New organizations start on the Compliance segment.

The framework and control catalog

Controls are one shared catalog. A framework does not own controls; it maps onto them.

Concept	What it holds
Frameworks	The requirement sets Noru knows about, for example ISO 27001 or SOC 2
Controls	The canonical catalog; a control id such as `IAM-01` is unique across all frameworks
Framework mappings	Which catalog controls each framework requires, with the framework's own clause reference (for example an ISO 27001 Annex A id)
Enabled frameworks	The frameworks your organization has switched on
Control status	Your status per control, with an optional reason and the date it was last reviewed
Control implementation	Owner (a member or a personnel record), notes, risk level, priority, and planned remediation

A control you have never touched shows as Not implemented. How the status moves is covered in Control status and coverage.

Generated identifiers

Evidence, policies, and risks get human-readable ids of the form NORU-EVD-n, NORU-POL-n, and NORU-RISK-n. They are assigned when the record is created, increase monotonically within your organization, and are never reused, so an id quoted in an audit finding always points at the same record.

How it works

The operating model

The modules form a pipeline. Each step feeds the next, and the last step is what auditors and customers see.

Settings and frameworks define organizational context and the requirement sets in scope.
Data sources collect system facts, evidence, assets, identities, findings, and privacy signals on a schedule.
Personnel, assets, vendors, and the privacy data map describe the people, technology, third parties, and processing inside that scope.
Controls, policies, risks, findings, and assessments record what should happen, what can go wrong, what was observed, and how you respond.
Tasks, training, internal audit, and review queues turn those records into owned work.
Evidence, reports, audit packages, and the trust center communicate the resulting posture.

Authored versus derived records

Record	Authored by you	Derived by Noru
Enabled frameworks; control owner, notes, priority	Yes	No
Control status	Yes, manually	Implemented, Pending review, and In progress can be set by the coverage engine
Evidence: file, link, note	Yes	Automatic evidence from syncs; Asset Register and Personnel Directory register evidence; module links; not-applicable and attestation rows from cloud auto-mapping
Policies	Yes	AI generation and regeneration; imports from uploaded evidence or connected data sources
Risks	Yes	AI-inferred risks from Organizational Risks Generation; risks imported from a data source keep a reference to their origin
Vendors	Yes	Auto-created when synced evidence names a third party
Security findings, certificate domains, third-party app grants	No	Written after each sync
Reports	You trigger them	Stored as an immutable snapshot

Derived records can be recomputed by the next sync, sweep, or regeneration. When you edit a derived evidence record, its provenance is re-attributed to you; see Evidence lifecycle and integrity.

Per-record logs

There is no single organization-wide audit log. Each module keeps its own append-only log, and each records a fixed vocabulary of actions.

Record	What its log records
Control	Status changes, note updates, evidence added or removed, remediation set, policy mapping verified
Policy	Created, updated, type changed, deleted, linked to or unlinked from a control, version created, draft opened from an approved edition, draft discarded, reverted to a version; every entry carries the policy version in force at the time
Risk	Created, updated, deleted, treatment created, updated, or deleted, control linked or unlinked, owner changed
Vendor	Free-text activity entries with details
Data source	One entry per sync: success or error, a message, and counts of items processed, failures, mappings generated, and duration

Actions taken through the REST API or the MCP server are logged the same way as actions taken in the app, attributed to the API key or the user that made them.

Where your data lives

Noru runs on infrastructure in the EU. Structured records live in a managed database; evidence files live in private object storage and are served only through short-lived, signed download links, never from a public URL. Credentials for connected data sources are stored encrypted and are decrypted only at the moment a sync runs; see Permissions and security and RBAC and security model.

Edge cases and failure modes

Segments are an organization attribute, not a user setting. Changing segments changes the sidebar for every member at once. A module hidden by segment still exists; its data is not deleted.
A control you never touched is Not implemented. Reports and exports treat "never set" and an explicit Not implemented the same way, but only an explicit status can carry a reason.
Derived records are overwritten by the process that owns them. A sync updates the automatic evidence it created; a register refresh rewrites Asset Register counts. Do not hand-edit the derived fields of such a record and expect the edit to last.
Logs are per record. To reconstruct everything that happened to a control you read that control's log; to reconstruct a sync you read the data source's sync history. There is no cross-record timeline, and automatic status flips made by the coverage engine write no control log entry (see Control status and coverage).
Catalog ids are global. A control id such as IAM-01 means the same thing in every framework and every organization. Framework-specific clause numbers are references onto it, not separate controls.

What you can influence

Frameworks in scope: Settings → Frameworks decides which catalog controls apply and therefore what coverage is measured against.
Ownership and intent: owner, notes, priority, planned remediation, and the status reason on each control are yours and are never overwritten by automation.
Which records you author: anything Noru derives you can also create by hand. A manual evidence record and an automatic one are the same kind of record; only provenance differs.
Segments: ask your Noru contact to change the organization's segments if a module you are entitled to is not visible.

Data model and operating model