Docs
relyance.ai ↗
Browse docs
Assessments

Legal and Compliance Guide

Updated October 22, 2026View as Markdown ↗

Audience: Legal, privacy, security, and compliance teams - no technical background required.

Not legal advice. This document explains how Relyance's Assessments module is built and what it lets you configure and evidence. It is not a legal opinion on what your organization is required to do in any jurisdiction. Work with your own counsel to determine your specific obligations.

Why assessments matter

Assessments exist to satisfy the same underlying regulatory pattern across several different drivers: a structured, repeatable process that identifies risk before it materializes, documents that the process happened, and can be produced as evidence later.

  • Data Protection Impact Assessments (GDPR Article 35) require organizations to assess processing activities likely to result in high risk to individuals before that processing begins, and to be able to demonstrate the assessment was conducted.
  • Vendor / third-party risk assessments support contractual due-diligence obligations and broader accountability frameworks such as ISO 27701, which expect demonstrable records that privacy impact assessments were conducted and reviewed. For example, a new vendor handling customer data can be put through a scoped security assessment as part of procurement intake, before the contract is signed, rather than as an afterthought.
  • Application security (AppSec) reviews follow the same shape even where no specific privacy regulation requires it: before a new system, integration, or vendor touches production data, a security team runs a structured assessment to document what was reviewed, what gaps were found, and who signed off - the same audit trail a DPIA produces, applied to a security rather than a privacy question.
  • AI governance - assessing AI models and cataloged AI use cases - supports emerging AI-specific obligations that follow the same shape: assess before you rely on a system, document what you found. For example, an AI use case can be assessed against a standard AI risk template before it's deployed internally, with the result exportable as a compliance package for that specific use case.

Relyance Assessments is built around that shared structure: a template defines what gets asked, an assessment instantiated from it captures what was found for a specific vendor, processing activity, AI model, or use case, and the audit log records who did what and when so the assessment stands up to later scrutiny.

What the Assessment Audit Log actually proves

Every save inside an assessment - a question answer changed, a section added, a status transition - is captured with the responsible user, a timestamp, and, for edits to existing values, the before and after state. This is what you hand an auditor or import into a GRC tool: not just that an assessment exists, but a field-level record of how it got to its current state. See Assessment Audit Log and Reporting for exactly what's captured and how to export it.

The audit log captures activity from the point the feature was enabled for your account forward - it does not retroactively reconstruct history for changes made before that.

Status, completion, and staying current

An assessment moves through statuses (for example, In Progress → In Review → Complete) as work on it progresses, and certain assessment types can require a prerequisite - such as an uploaded Data Processing Agreement - before they're eligible to be marked complete. Relyance also separately tracks when the template an assessment was built from has since been updated, so you can see the history of template changes against a given assessment.

Marking an assessment complete is not the end of the story. Where Attestations (below) are enabled, a completed assessment can flip back to Needs Review if the record it concerns changes afterward, so a completed DPIA or vendor assessment doesn't silently go stale the moment the processing activity or vendor relationship it covered changes. This is a meaningful compliance detail - it's the difference between "we assessed this once" and "we have a live signal telling us to reassess," and it ships with a per-field delta (old value, new value, source, timestamp) rather than a vague "something changed" banner.

Sharing and restricted access

Assessments can be shared with internal owners and external stakeholders, and access to a given assessment can be restricted to specific, named email addresses. Comments attached to individual questions give reviewers a way to raise and resolve issues without leaving a paper trail outside the platform.

A generic shareable link (for example, one posted in an internal wiki rather than sent to a named stakeholder) is not yet guaranteed to associate the completed assessment back to a specific entity - the entity-selection step that makes that association reliable for generic links is still rolling out. Assessments created directly against a specific vendor, processing activity, AI model, or AI use case don't have this gap; treat Attestations and Needs Review as fully reliable only for assessments created that way until your account team confirms otherwise for shared links.

Attestations: where assessment- and contract-sourced data lives

Where enabled, every entity page - vendor, processing activity, product, AI model, AI agent, MCP server, AI SaaS vendor, and more - has an Attestations section, structurally separate from the entity's Findings. Findings are what Relyance observed through a live scan or integration; Attestations are what a human told Relyance through an assessment or a contract. Keeping them apart matters for defensibility: an auditor or your own security team can see at a glance whether a given field value on a vendor or processing activity was independently discovered or self-reported, rather than one undifferentiated "current state."

Concretely, this is what the pre-fill/push-back capability described in the API Reference looks like in the product:

  • Before an assessment is even created, each template question shows its predicted target field and entity type, so you know up front what it will read from or write to.
  • On open, an assessment against an existing entity pre-fills every mappable question from that entity's current data, visibly marked as pre-filled rather than human-entered.
  • On completion, you see a diff-style preview - every entity and field about to change, old value versus new value - and must confirm before anything writes. Nothing is pushed silently, and if the record changed since that preview was generated, the push is refused rather than applied against stale data.
  • If the underlying entity changes after completion, the assessment moves to Needs Review rather than silently drifting out of date. The Needs Review view lists exactly what changed - per field, with the old value, new value, source, and timestamp - and you can accept or override each change individually; completing the review returns the assessment to Completed.
  • If two sources disagree about the same field - say, a live scan and a self-reported assessment answer - you see what was overwritten and which source did it, rather than a silent overwrite.
  • Clicking into any Attestation's source opens a drawer identifying the exact assessment question (linked to the assessment itself) or contract clause that produced that value - the traceability a regulator or auditor would actually ask for.

AI-assisted answers, and keeping them distinguishable

Separately from Attestations, an AI Assistant can answer certain question types directly inside an assessment by reasoning over available context, rather than only mapping to a known field. Every answer it provides is flagged in the UI as AI-generated, and an agent drawer on the assessment lets a reviewer follow its reasoning before relying on the answer - the same principle as Attestations' source traceability, applied to a different mechanism. As with any AI-assisted output you intend to rely on for a regulatory filing, treat it as a draft a qualified reviewer signs off on, not a final answer.

← Previous
Overview and Implementation Guide