FAQs for Tech Risk & Compliance

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.

The Managing Library Evidence Tasks in Bulk article outlines how to add several custom evidence tasks to your compliance initiatives.

Before removing an evidence task implementation, review its associated control implementations to understand the impact. If it is linked to multiple control implementations, it will be removed only from the selected control implementation. If it is linked to a single control implementation, it will be permanently deleted along with any associated evidence and attachments.

You can remove an evidence task from a control by unlinking the evidence task. Begin by opening the evidence task’s details page and selecting Controls in the Associations card (on the right-hand side) and then Edit associated controls. Locate the control you want unlinked and select the X icon beside it. Select Save Changes to complete the process.

When an evidence task implementation is removed from a control implementation, any associated evidence and attachments may also be deleted. Because the system does not support evidence task implementations without a control implementation relationship, removing the final associated control implementation permanently deletes the evidence task implementation and its data.

Navigate to the evidence task’s actions menu and select Upgrade/Reset. The evidence task name and summary will be updated, while the collection interval and evidence guidance will remain the same.

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.

A user can see an evidence task when the related evidence is linked to an entity in their current organization or in a child organization.

No. Visibility is not limited by the evidence task’s primary entity. If the evidence is linked to an entity in the user’s current organization or a child organization, the evidence task can still be shown even when its primary entity belongs to a different sibling organization.

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.

An admin can assign a collection subtask to “any assignee.” Filtering on the evidence details page by a specific collection subtask assignee will show the collection intervals with subtasks they have been specifically assigned to, as well as collection intervals with subtasks assigned to "any assignee."

By default, a subtask assignee is added as an assignee of the evidence task the subtask belongs to.

A required subtask is a subtask that has to be collected to achieve full compliance with a collection interval. You can collect evidence and tag it with a subtask before its “effective from” date. However, this will not apply any collection metrics to that interval.

A current collection interval with an “in-progress” blue state means that at least one but not all required collection subtasks for that collection interval have been collected.

Yes. Notifications are included in the following notifications emails:

• Evidence task assignment

• Evidence digest email sent weekly on a Monday

If you see “No Intervals” listed when you filter for an evidence task assignee, this is because that assignee is not an assignee of any collection subtasks.

Yes. You can also clone readiness projects containing evidence tasks with collection subtasks. The behavior is the same whether you clone an individual evidence task with collection subtasks or clone a readiness project containing evidence tasks with collection subtasks.

Cloned evidence tasks with subtasks include the following cloned subtask information:

• Collection subtask description

• Collection subtask ID

• Effective from date

Cloned evidence tasks with subtasks do not include the following cloned subtask information:

• Collection subtask assignee

• Collection subtask attachments

Yes. We recommend reviewing your collection subtasks before and after accepting our content updates to an evidence task to ensure the collection subtask requirements remain aligned with the updated 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.

Automated Evidence Collection provides step-by-step instructions to set up each integration. Once the user has followed the instructions and configured the integration, the integration will fetch all of the target data. If there are any issues with network or user credentials, then the integration will not bring any data. So an integration is set up to fetch all or none; hence Automated Evidence Collection and the user will know if the integration is giving errors.

For more information, see Configuring Automated Evidence Collection.

Automated Evidence Collection allows customers to update the configuration setup anytime they want (e.g. frequency of collection). However, the output file or data generated through the integration is non-modifiable on the Automated Evidence Collection platform.

Automated Evidence Collection follows a robust change management and access management process to ensure access is restricted and that the production code cannot be directly modified. If Automated Evidence Collection updates the API code for an existing integration, we make sure to announce it to customers.

Besides, Automated Evidence Collection encrypts the customer credentials in the database to ensure security and confidentiality.

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.

Yes. Automated Evidence Collection’s experienced engineers support integration operations. Any issues with the working of these integrations get notified, recorded and timely resolved.

Automated Evidence Collection tests every integration in the test environment before migrating it to production. During the testing process, Automated Evidence Collection checks to ensure an integration is configured to pull the correct data, which is complete and accurate to meet the Evidence Task requirements.

The "New" stage is for new audits which have not started or are still being planned.

The "Field Work" stage is when you are working on completing workpapers and findings.

The "Completed" stage is when the audit is complete, and all workpapers/findings have been completed and reported.

To use a custom framework within an audit, you must add that framework to your Controls Library. To do this, click the Add New button to view the Add New Custom Control screen. From here, you can add a control and define the standard/framework as the name of your custom framework. Once added, you can add more controls to this framework.

You can also perform a bulk import on the Controls Library. In the bulk import spreadsheet, you will need to ensure the controls being imported have the framework defined as your custom framework.

Once added, you can create an audit and the custom framework will be available to select in the standard/framework field selector.

To edit the scope of an audit, choose an audit from the Audit list screen and select the Scope tab. Click the Edit Scope button to open the Assign Auditors screen. From here, you can reassign the auditor on the workpaper or add controls to the audit.

You can add controls to your audit for the framework the audit is on. Once added, the controls are added to the audit workpapers and you are taken back to the Edit Audit Scope screen.

To delete a scope, navigate to the Scope menu on the Audit Details screen. Hover over the control you would like to delete and click the Context menu. This will give you the option to delete the scope, which will remove the scope and workpaper from the audit.

You can do this in one of two ways, depending on the needs or your organization.

First, you can create a custom role and give them access to view, add, and edit all organizational audits, workpapers, and findings. This will ensure the user can view the audit and contribute as needed.

The second option limits the user access. To do this, make the user an approver on the audit they will need to assist on in order to give them the visibility needed to edit the audit.

To log a finding, navigate to the workpaper containing the control you want to log the finding against. From the Workpaper Details screen, select Findings, and then click the Log Finding button. On the Log Finding screen, add a new finding.

The newly added finding can be found in the Findings list screen on the workpaper it was created against as well as in the Findings menu. For more information, see Adding and Managing Audit Findings.

You can create an audit report within the Audit Management module. To do this, click the Context menu on the audit in which you would like to create a report, and then select Export as PDF. This will create a PDF report which will be available for download.

You can also create an audit report using the Reports module. Click the Create New button to open the Select Template screen. From here, you can select Audit Management as the data source and then create a custom report or audit default PDF report.

The permissions associated with this feature are:

• Workpaper Workflow Approval

• Audit Workflow Approval

Yes, approvers will receive the Approval Needed email when they are assigned as an approver.

No. There is no limit to the number of approvers you can add to a workflow stage.

Yes, users can view the complete audit history of a workflow that includes details of all approvals and rejections by the approvers. This Audit History appears on the Workflow and Approval tab. The Workflow and Approval tab only appears if you are using an advanced workflow.

Yes, you will receive the Approval Needed email.

Only current stage approvers of the document can see this button.

If you reject an audit or workpaper as an approver, an email will be sent to the auditor. The workflow stage will not advance automatically.

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.

You can edit a document by opening the document and navigating to the Builder. The document can be configured to include various sections in a layout that meet the needs of your organization. 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 track the change history of a document by accessing the Activity tab on the Details screen.

Yes, document owners receive email notifications when a document is expiring or has expired.

If a document has multiple owners and one owner is deactivated, email notifications sent to policy owners will continue to list all owners in the email template, including the deactivated user. Once the deactivated user is manually removed from the document and emails are triggered again, the inactive user will no longer appear in the email template.

You can add and manage controls to individual sections of a document by clicking the Manage Controls button when editing a document. See Managing Controls in the OneTrust Builder for more information.

You can relate assets, processing activities, vendors, entities, policies, standards, and procedures to a document using the Related tab on the Details screen. For more information, see Relating Inventories to a Document.

You can link and manage the controls related to a document using the Controls tab of the Details screen. For more information, see Linking Controls to a Document.

You can use the Attribute Manager to create custom attributes for your documents. For more information, see Adding, Editing, and Deactivating Policy Attributes.

Custom attribute fields will display when creating and editing documents.

The permissions associated with this feature are EPM Workflow and Approval Tab and EPM Bypass Required Approvals.

The EPM Workflow and Approval Tab permission allows users to view the workflow and approvals tab of documents using approval workflow stages.

The EPM Bypass Required Approvals permission allows users to skip required approvers within workflow approval stages.

No. Only users with the EPM Bypass Required Approvals permission can bypass other approvers. The roles with this permission are Site Admins and EPM Managers.

The EPM Workflow and Approval Tab permission allows the ability to add user type attributes as approvers.

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 Admin and EPM Manager roles can create or cancel an attestation. All users can edit the details of an attestation.

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, attestations are linked to a published standard, policy, or procedure. If a document with a related attestation is deleted, the attestation will also be deleted.

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

Yes. Documents created using the Microsoft Word Online feature can still be used to send attestations. Users without a Microsoft Word license can still view document content and attest.

You can enable this toggle to automatically update the respondents list with any changes to the organization. The respondents list will be updated immediately.

For example, if users are added to an organization, they will automatically get attestation invites immediately if the toggle is enabled.

The respondent list will be updated immediately after a user's organization is changed to the same organization selected on an active attestation.

If a Site Admin or EPM Manager cancels an attestation, all respondents will be informed via email that no further action is required. If the attestation is later restored, all respondents will be informed via email that they have to acknowledge the document.

Yes, any attestation in the Not Started, Active, or Canceled status can be deleted.

This role can navigate to the Self Service Portal and Employee Portal to view policies, access the help center settings, and access basic CORE functionality such as tasks, settings, notifications, etc.

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.

Attestation Respondents can view a list of all their exception requests in the Self-Service Portal. To view your requests, navigate to the Self-Service Portal menu, select My Documents, and then select the My Exceptions tab. For more information, see Requesting Exceptions and Extensions.

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.

An incident is an unplanned event that disrupts operations or poses a threat to security and requires immediate action.  The nature of issues is often more proactive or preventative. While issues can affect the performance or compliance of IT systems, they may not require immediate action and can be monitored and addressed over time. Example: A data breach or system outage.

Issues represent problems that need resolution, while exceptions are formally reviewed and accepted deviations from policies and controls. Issues generally require corrective actions while exceptions involve documented justification for non-compliance.  Example: A system does not meet the requirements to have a minimum password character count, but an exception was granted because it's a legacy system.

Third-Party Risk Management Use Cases

Vendor Assessments

: Documenting and tracking findings from due diligence, security questionnaires, or periodic risk assessments.

Data Breach or Security Incident Involving a Vendor

: Responding to incidents where a vendor mishandles or leaks sensitive data.

SLA or Performance Breaches

: Monitoring and managing contractual non-compliance.

Regulatory or Legal Non-Compliance

: Identifying risks when a vendor is found non-compliant with regulatory obligations.

IT & Security Risk Management Use Cases:

• Control Self-Assessments: Configure assessment rules to flag issues based on responses and flag issues while reviewing assessments.

  • Internal Control Failures: Keep track of issues identified in internal or external audits and assessments

• Inventory Assessments

  • Technology Updates: Manage issues related to outdated software or hardware that may pose compliance risks, prioritizing updates based on risk assessments.

• Risk Assessments

  • Logging issues as part of a risk assessment to identify gaps and actions needed to mitigate the risk, from an assessment or the risk record directly.

• Use issues as part of an intake and triage process to identify risks.

Compliance Automation Use Cases:

• Regulatory Compliance Audits: Track issues against evidence tasks and controls when additional follow-ups are needed to achieve or maintain compliance as part of an internal readiness exercise or external audit.

Enterprise Policy Management Use Cases:

• Policy Violations: recording and addressing violations of internal policies, procedures, and standards.

• Training and Awareness Gaps: Track issues related to employee training on compliance policies.

Issues Creation

Create issues individually from the issues register, directly on an object, in bulk via import templates, automatically via assessment rules, or while reviewing an assessment.

Issues Remediation

Streamline and document the process of remediation review and approval with workflows. Dynamically change workflows based on issue attributes. Create tasks to track and assign remediation work.

Issues Relationships

Relate a single issue to multiple OneTrust inventories and objects to map impact. Available objects include:

• Assets

• Control Implementations

• Entities

• Evidence Tasks

• Policies

• Procedures

• Processing Activities

• Risks

• Standards

• Vendors

• Engagements

• Exceptions

Issue Reporting

Dashboards

• Gain insights into issues trends that need your attention.

• Automate issues status reporting.

Column Reports

• Automate issues status reporting.

Issues Impact on Risks

• Track the quantitative impact of issues on risks by including issue attributes in risk formulas.

• Get notified when an issue closes on a risk or control so you can manually adjust the risk score as needed.

For more information, see the Issues Management knowledge base.

Issues Management is available for customers who are licensed to the following products: IT & Security Risk Management, Enterprise Policy Management, Compliance Automation, and Third-Party Risk Management.  Privacy customers who also have the products listed above will have visibility to issues created on shared inventories and can create issues from those inventories. 

The Issue register appears in the side navigation for all users.

However, the issue data shown in the list view depends on access. You can view issue data if you have permission to view issues, or if you are assigned to the issue as the Owner, Approver, or Stage Approver.

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

View the reports available in the Notifications popover. The Issue Conversion Export will display conversion details and errors. The Issue Management notification will take you to the Converted risks screen where you can view newly converted issues. You can also view the Converted risks screen when you submit the conversion.

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.

The risk owner and approver are notified when a risk is converted to an issue.

The Risk to issue conversion summary email template is used to notify risk owners and approvers when a risk is converted to an issue.

You can find the Risk to issue conversion summary email template and description template under Global Settings > Email branding & templates.

Yes. Navigate to the Converted risks screen by clicking the Context Menu icon on the Risk register screen to view converted issues.

Yes. Attribute visibility rules will apply when you create a new issue, update an existing issue, or view and issue. No additional action is required to run or enable the visibility rule.

When an existing visibility rule is edited, the updated logic will be applied to new issues and existing issues once they are viewed or updated.

No. If an attribute already contains values and a visibility rule later hides that attribute, the existing data remains intact. The system will not clear, overwrite, or modify previously stored values. The visibility rules only impact user interface visibility changes, your historical data stays preserved.

The field will be hidden when creating or updating an issue unless the conditions are met to display it.

Rules run in the order they appear on the Attribute visibility tab of the Issue type details screen. You can change the order of a rule from the Context menu on this screen.

No. Attribute visibility rules only apply to the user interface (UI). Reporting, analytics, exports, and API queries continue to include all underlying data, even for the attributes hidden by the visibility rules. Reports will always reflect the full dataset, not the UI visibility configuration.

The best system role available for someone managing the IT & Security Risk Management module would be the IT Risk Manager role. For more information, see Managing GRC Roles.

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

No. Users must update the framework to import risks and business objectives. This helps to prevent the creation of duplicate records that may not be needed.

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

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

You must have IT Risk Management (Enterprise or Standard SKU), Tech Risk & Compliance, or Third-Party Risk Management (Enterprise or Standard SKU) to access risk automation rules.

Yes. You have a parameter to set if you want the rule against inventory records in specifically the organization set on the rule or on all of the organizations that roll up to the organization set on the rule itself.

Only records with an Active status will be considered when automation rules are executed.

Currently, the text type attributes are not supported for automation rules. However, the date, single select, multi-select, user, and country type attributes are supported.

No. However, if you have a condition you are trying to create to view multiple values for a single attribute, simply create multiple condition blocks with the same attribute and use the 'Or' operator between these values to construct your rule.

No, they cannot see the rules you create. If a user in a lower organization has access to the automation rules user interface in a lower organization, the user can only see the rule group name in a non-edit state. They are unable to go into the rule group detail to view the rule list or make changes to rules in higher organizations.

For custom date type attributes, setting a condition of days before means the system will evaluate if your date values are in the future. Here are some examples of what to expect. For more information, see Rule Examples for Custom Date Attributes.

• Today is May 1st.

• Less than or equal to 30 days before today would start a trigger for date values in the range from today to June 1st. This is because June 1st and all dates before are within 30 days away from today.

• Greater than or equal to 30 days before today would start a trigger for date values in the range from June 2nd and beyond. This is because June 2nd is greater than 30 days away from today.

• Greater than or equal to 30 days after would trigger for date values in the range from April 1st and all dates prior. This is because April 1st and all dates before are greater than 30 days prior to today.

The COUNT of risk is not supported for inventory aggregation in Global Settings. To set up the COUNT of risks, the user must go to the Attribute manager, open inventory attributes, and update the aggregate risk score formula attribute to include the COUNT of risk use case. Here is an example formula for COUNT of risks:

In the formula above, the following are true:

• If the count of Residual Risk Score = Very High is greater than zero, then the aggregated score is 4 and the level is Very High.

• If the count of Residual Risk Score = High is greater than zero, then the aggregated score is 3 and the level is High.

• If the count of Residual Risk Score = Medium is greater than zero, then the aggregated score is 2 and the level is Medium.

• If the count of Residual Risk Score = Low is greater than zero, then the aggregated score is 1 and the level is Low.

• If none of the above conditions are satisfied, then the aggregated score and level are set to NULL.