Completeness and Accuracy Procedures
Procedures for validating completeness and accuracy to meet audit requirements, such as requirements for SOX, SOC1, and SOC2.
Last updated
Was this helpful?
Procedures for validating completeness and accuracy to meet audit requirements, such as requirements for SOX, SOC1, and SOC2.
Last updated
Was this helpful?
Was this helpful?
A management review control is a type of internal control where management evaluates financial, operational, or system information—such as estimates, forecasts, reconciliations, or user listings—to detect errors, inconsistencies, or unusual trends. Its effectiveness relies on the integrity of Information Produced by the Entity (IPE), as decisions are based on that data.
User access reviews (UAR) control is a management review control. As part of UARs, reviewers rely on either an export from the source system under review or an automated Identity Governance and Administration (IGA) tool, such as the Veza platform, that's integrated with the source system to perform the review. Relevant data from the source system would be automatically pulled or uploaded to the IGA tool.
Audit guidance for SOX and other compliance frameworks, such as SOC1 and SOC2 for management review controls, is that auditors should review management's procedures over completeness and accuracy of the IPE. Therefore, for user access review controls, control owner and/or control operator (e.g. the person who creates the review, the person who performs the review, the person who signs off the review) should perform procedures to validate the completeness and accuracy of user listings under review regardless of leveraging an IGA tool or performing manual reviews from a data export. Such procedures would be the 'Management's procedures'.
Note: Certain organizations perform role-to-permissions reviews for in-scope applications. Such reviews help to ensure that the permissions tied to roles are set as expected. Though the procedures listed below focus on user access reviews, the same procedures can be applicable to role-to-permission reviews as well.
Customers can use a combination of the below procedures, though final say about what's minimally required is best assessed internally with the customer's internal and external auditors. Note that some auditors may demand that you perform all of the procedures below as well as additional procedures, for example, reviewing and documenting integration configuration periodically.
To validate completeness: Reconcile the total number of source system user records vs. the total number of users for that source system reported by Veza. If total counts of users are not available in either system, trace a sample of users from the source system to Veza and make sure no user is missing.
To validate the accuracy: Trace a sample of source system users reported by Veza to the source system, and make sure no user is missing. For the sampled users, validate that the users' attributes, such as name, role, or group, etc, are the same between Veza and the source system.
Note: There are situations where Veza can return more users than displayed in the source system. This scenario is quite common, and it does not mean that the Veza platform is inaccurate. For example, Veza can pull resource data via source system APIs, which could return a more comprehensive list of entities than displayed by default in the source system UI.
When creating an access review in the Veza platform, review the access review's configuration before creating the first review to ensure the configuration is set as intended.
Note: To obtain a review configuration's creation and last modification date, you can refer to the corresponding user access review's PDF export.
For reviews that exclude certain types of users, it is critical to ensure that the exclusion is clearly documented by the review creator and auditor for transparency
IMPORTANT This procedure is highly recommended when a review configuration is used for the first time.
In the 'Administration' tab, Veza's event log contains 30 days of change history in the UI. If customers need to retain more than 30 days of data, then they can leverage a SIEM, such as Splunk, Elastic or others to retain their data. Either Veza Events API or Audit Log Event API can be used. For documentation see: Events API, and Audit Logs API
Option 1: Enable Data Source Status Acknowledgement function to review the health of the data source sync when the applicable graph snapshot was taken. After acknowledgement, the review will be created from the same graph snapshot. This is how you guarantee that the integration was healthy for your review.
Option 2: Prior to creating a review, go to the Integration page and 'Start Extraction' for the data source corresponding to the source system. Once the data extraction status shows 'success', create the user access review.
Note: For customers excluding certain entitlements from their user access reviews, it is crucial to provide documentation and justifications to the auditors why certain entitlements are excluded (e.g. read-only roles). Some best practices include:
Apply Veza tags to all target resource roles or groups (e.g., tagging roles with 'SOX: in-scope' vs. 'SOX: out-of-scope').
Note that you may need to justify to your auditor when certain entities were tagged out of scope.
Querying all roles or groups for a target resource, including tagged or untagged roles/groups, and
Performing a review to ensure tags have been correctly applied to all roles or groups exhaustively.
Note: It is best to perform this analysis against a specific graph snapshot. Also, the results from this query can also be used to perform correctness and accuracy reconciliation when performing role-to-permission review.
Review Configuration: Once the aforementioned tag review has been performed, set up a query that identifies users and roles/resources with desired tags, such as 'SOX: in-scope', and use that query in the Review Configuration.
Define Review Timeframe: The snapshot date should be the same date when the tag review is performed. For example, if the tag review is performed on 5/31/2025, and the review is created on the same date, then choose 'From the most recent daily snapshot'; if the review is created on 6/1/2025 or later, then choose 'From Another Snapshot' and choose '5/31/2025' as the date.
Set up Alerts and Veza Actions when a new entitlement is created and/or when an untagged entitlement shows up from the source system.
See Rules and Alerts
It is important to document procedures performed. It is not required that you take screenshots, but screenshots can help save time when explaining the procedure performed to auditors. Sign off and date the procedure is also recommended.
In addition to the completeness and accuracy procedures mentioned above, customers should implement IT general controls (ITGCs) for Veza to ensure that certain authentication, access controls, and change management controls are implemented. The ITGCs are also management's procedures over completeness and accuracy of the report. See here for an explanation of ITGCs from an audit firm.
Organizations should consider their IT environment and the robustness of the controls to determine what completeness and accuracy procedures should be conducted.
To ensure the health of the integration, here are additional best practices we recommend the customers adopt:
Regularly monitoring the health status of integrations.
Ensuring integrations are set up with correct credentials and sufficient scope such that all required entities from the source systems/applications are extracted and loaded into the Veza Access Graph.
When there is a change in the source system, evaluate the change and assess if such a change would impact integration with Veza.
Failure to perform these procedures might result in out-of-date or incomplete source system data in the Veza platform. Moreover, if a completeness and accuracy reconciliation encounters issues, such as non-reconciling records or counts, the root cause can often be traced to an unhealthy or improperly configured integration.
Customers should evaluate the risk of the overall IT environment, history of access control failure, and robustness of other ITGCs to determine how frequently these procedures should be conducted.
In an environment where there are sufficient ITGCs over Veza, such as a documented review change control procedure is followed when making changes to Review Configurations; admin and operator access is tightly controlled, etc., then the procedures can be less frequent. In an environment where there are no robust ITGCs in Veza, the procedures may need to be more frequent. Your internal or external auditors should be able to tell you whether you're performing the procedures frequently enough.
In some cases, customers could perform and document the completeness and accuracy procedures performed during the Veza implementation phase (part of their SDLC procedures), and rely on ITGC controls onwards.
Additionally, customers may be qualified to benchmark the Review Configurations, in which case, the auditors would examine the report logic once and wouldn't need to examine it again for 2-3 years when the configuration has not changed or changed minimally. Typically, with strong ITGCs over Veza, auditors would consider adopting benchmarking. Customers can discuss that qualification with their auditors.
Integration discrepancies can occur when entity counts or attributes don't match between Veza and the source system. Use this approach to identify and resolve common issues:
When Veza displays fewer entities than the source system:
Data synchronization delay – New data may not have synced to Veza yet. Check the integration's last successful extraction time on the integration Details page. Manually trigger an extraction or wait for the next scheduled sync.
Authentication issues – Verify that integration credentials are valid and haven't expired. Review any authentication errors in the Events page.
Scope limitations – Confirm that Veza has been authorized to access all required data sources and organizational units within the integration scope. The specifics vary between Integrations.
Integration sync failures – Check for partial extraction failures that may have prevented complete data collection. See individual integration guides for integration-specific troubleshooting steps.
When entity attributes don't match between systems:
Data synchronization delay – New data may not have synced to Veza yet. Check the integration's last successful extraction time on the integration Details page. Manually trigger an extraction or wait for the next scheduled sync.
Integration sync failures – Review integration details for any missed extractions due to missing permissions or connection issues, which could result in stale data in Veza.
For persistent issues or complex troubleshooting scenarios, contact Veza technical support for specialized assistance.