FAQs for Managing Risk and Compliance

All frameworks except for legacy frameworks include risks and business objectives. Legacy frameworks do not include risks, business objectives, and evidence tasks.

Yes. The framework import includes mappings between controls and risks.

No. Risks are not added to the Risk Register during the control implementation.

Evidence tasks are the proof you collect that your organization has the correct control in place and that the control is operational. Each evidence task has its own evidence requirements  and collection interval, and an evidence task may be associated with more than one control.

Evidence tasks are added or linked to initiatives through their associated controls. When a control is added to an initiatives, the evidence tasks associated with that control are also added. Similarly, when a control is removed from an initiatives, the associated evidence is also removed (unless the evidence is linked to another control within the initiatives).

You can manually create a custom evidence task on the Control Details screen. Custom evidence tasks may be created in cases where OneTrust does not support the standard or framework needed out-of-the-box. For more information, see Creating and Managing Custom Evidence Tasks in your Library.

You can also add an evidence task to your initiatives by associating it with an inventory, control, policy, or issue.

Although you can associate an evidence task with procedures at any time, some evidence tasks require an associated procedure to prove the control has been implemented.

To add an associated procedure to an evidence task, export the procedure and then attach it as evidence to the evidence task.

The evidence needed for each evidence task is unique. To view the evidence requirements for an evidence task, open the evidence task’s details page and navigate to the What to collect section within the main Evidence Task screen.

A collection interval indicates how frequently you should collect evidence for an evidence task (e.g. weekly, monthly, quarterly) based on your organization’s calendar start month. Collection intervals are also impacted by a readiness project’s observation period, as it determines which intervals apply to an evidence task.

You can view the collection interval for each evidence task by opening your initiative and selecting the Evidence Tasks tab. Select the evidence task to open the evidence task’s details screen, and navigate to the Compliance card on the right-hand side.

During external audits, auditors sample random dates and review the evidence collected within each sample to evaluate your organization’s framework compliance. Each evidence task has a collection interval that outlines how frequently the evidence must be collected to meet this audit requirement (e.g. weekly, bi-weekly, monthly, quarterly, yearly, etc.).

There are a few ways to attach evidence to an evidence task, and one is by setting up automated evidence collection to automatically collect evidence from other applications. The collected evidence is compiled into a report and attached to the evidence task(s) you selected during the integration’s setup.

You can add evidence attachments manually by opening an evidence task’s collection interval, selecting Add Evidence and adding your file, link or note. Only one attachment type can be selected per attachment. Alternatively you can add evidence attachments in the When to Collect guidance by clicking on collect evidence without setting an interval.

See Automated Evidence Collection Integrations FAQ for more information about integrations.

If you’ve collected evidence but the collection interval has already passed, you can open the evidence task and navigate to the overdue interval. Select Add evidence and then select the date the evidence was gathered. Choose the attachment type, upload the file and select Collect evidence. The evidence will now appear in the appropriate collection interval.

If a collection interval has already passed but the evidence has not been collected, you can choose Note as the attachment type and add a note to provide further details. Notes will be visible in the corresponding audit project(s).

This is expected behavior when an initiative is created after a compliance interval has ended. For example, if an initiative and its evidence are implemented on 10 July 2026 with an observation period spanning 1 July 2025–31 July 2026, Compliance Automation generates intervals according to the initiative configuration and compliance calendar:

1 July 2025–30 June 2026

Marked Overdue because this historical interval had already ended when the evidence was implemented.

1 July 2026–30 June 2027

Marked Not Collected with a due date of 15 July 2027 because this is the current active interval.

Due dates apply only to the current, active interval. Annual intervals follow the defined compliance calendar; they are not calculated as a rolling 12-month period from the initiative creation date. Therefore, when an initiative is created after an interval has ended, the system generates that historical interval and its related review tasks as overdue. Compliance Automation is designed for evidence collection during the defined collection period and does not support retrospective collection for a closed interval without an overdue status. For future initiatives, align the initiative duration and compliance calendar so that the calendar start month matches the beginning of the intended observation period.

An ad hoc evidence task is an incident-based evidence task (triggered by events) that may not occur within each interval.

Ad hoc evidence tasks will only be marked compliant or complete within an audit project or readiness project if evidence has been collected within each collection interval. If an incident or trigger did not occur in that collection interval, you could satisfy the collection interval by adding a note attachment to indicate this. See the Evidence Collection FAQs for more information.

If you are in an active audit, we recommend waiting to create collection subtasks until the audit is complete. This is to avoid any interference with your audit. We also recommend creating collection subtasks if you need to assign multiple individuals to different parts of an evidence task or need to track the progress of attachments being uploaded to an evidence task.

Automated evidence integrations automatically collect evidence from other applications. The collected evidence is compiled into a report that you can use to address a specific evidence task in your compliance initiative. Each satisfied evidence task supports at least one of your implemented controls, and this brings you one step closer to completing your compliance initiative.

Automated Evidence Collection provides over 50 collectors across 30 systems to help customers collect evidence for different categories of controls. For more information, see the full list of implemented integrations and associated evidence tasks.

Yes. Automated Evidence Collection has put all measures in place to ensure it satisfies Automated Evidence Collection’s internal controls requirements to provide customers and their auditors assurance over processing integrity. You can download automated evidence collection (AEC) sample reports as Excel files to view the test data available for all evidence integrations. For more information, see Downloading Sample Reports.

We also include “Processing Integrity'' (see note below) as one of the Trust Service Categories in our SOC 2 report, which can be obtained on a request basis.

You can create a custom document by clicking the Create button on the document list screen. For more information, see Creating a New Custom Document.

Yes. OneTrust has created the Policy Gallery to assist with building enterprise policies. See, Using the Policy Gallery for more information.

You can use the Policy Builder or MS Word Online to configure content. For more information, see Building and Editing a Document.

Once you configure a document, click the Publish button to publish your updates. The Save button will save all changes made to a document without publishing. For more information, see Building and Editing a Document.

To create a new version of an existing document, open the document and click the Create New Version button. This will open the Builder, where you can edit the new document.

You can create and send attestations from published policies in the Policy module. To create and send an attestation, navigate to the Attestations menu. For more information, see Adding, Editing, and Canceling Attestations.

Site Admins and EPM Managers have the ability to send attestations to respondents. They can send the attestation to an entire organization, sub-organization, individual users, invited users, or to imported users via Users and Groups settings. Once an attestation is sent, respondents will receive an email invite to acknowledge the attestation. When an attestation is sent to respondents, it is considered an active attestation.

Yes. If you create a new version of a document, a new attestation will need to be sent to respondents.

Site Admins can view a list of all exceptions on the Exception Register screen. To navigate to the Exception Register screen, click Exceptions on the Policy menu.

An issue is a deviation, deficiency, or event that introduces risk to systems, data, operations, or compliance—often requiring documentation, remediation, and potential escalation. Example: A system did not meet requirements for a minimum password character count.

Risks are potential events with material impact on an organization in achieving its objectives. Example: loss of personal data.

An issue is an instance when there has not been appropriate action to mitigate risk to an acceptable level. This event has materialized a risk into existence or increases the likelihood of the risk occurring.

Yes. You can use the Create Issues import template to bulk import new issues and the Update Issues import template to bulk update issues.

For more information, see Managing Issues in Bulk.

Risk data will be transferred to the corresponding tabs on the issue record. The data that will be transferred includes:

• Activity - will be included on the Activity tab of an issue record. It will only capture events since the record was converted to an issue. You can view the risk activity by clicking the View risk activity button that at appears in the activity history.
  
  

• Assessments - will be linked on the Source Attribute of an issue record

• Attachments - will be included on the Documents tab of an issue record

• Attributes - will be included on the Details tab of an issue record

• Comments

• Controls - will be included on the Related tab of an issue record. If a control is implemented directly on a risk and that risk is later converted into an issue, the control’s source reference on the issue will no longer be linked/related because the original risk no longer exists. While controls can be implemented on risks and mapped to issues, control implementations themselves cannot be converted to use an issue as the source.

• Related Objects (inventories, controls, policies, etc.)

• Tasks

Risks that failed the conversion will no longer be visible on the Risk register screen. To view these risks, navigate to the Converted risks screen. These records will display a Failed status.

When a risk fails to convert to an issue, OneTrust recommends triaging the issue, updating the mapping (if required), and retrying the conversion. You can also restore the risk so that it returns to the Risk register.