Example Evidence Not Monitored Controls (Microsoft Supplier Security and Privacy Assurance (SSPA))

This article is meant to provide examples of evidence for the ‘Not Monitored’ Microsoft SSPA Controls in Drata. For each Control, you’ll find one or more examples of evidence to upload.

NOTE: This document should not be interpreted as legal advice. When supplying evidence for Controls, you should always have your legal team review the evidence to ensure that documents are appropriate for your organization’s specific facts and circumstances. In addition, we cannot guarantee that the recommendations provided below will meet specific requirements of the Microsoft SSPA.

Code	Name	Evidence
DCF-16	Periodic Risk Assessment	Upload your most recent risk assessment report.
DCF-19	Penetration Tests	Upload your most recent annual penetration test.
DCF-20	Asset Inventory	1. Formal, documented listing of all assets (workstations, mobile devices, servers, databases, etc.) - and - 2. For cloud infrastructure, screenshots from cloud environments listing all infrastructure
DCF-26	BCP/DR Tests	Upload most recently completed BCP/DR test.
DCF-46	Formal Screening Process	Upload evidence of the formal interview/recruitment process for a recently hired personnel. Example: Calendar invites for interviews, documented feedback notes from interviewers, exports from the candidate's profile within the applicant tracking system, evidence of evaluation of resume and professional credentials, etc. Note: For many controls, auditors may request a complete population of applicable items (e.g., users, assets, vendors) and select a sample for evidence review. One example may not be sufficient unless explicitly agreed upon in scope.
DCF-64	Commitments Communicated to Customers	1. Upload evidence of a recently executed service agreement with a customer. - and - 2. Upload evidence of your terms of service available online, as well as screenshots of the account sign up process showing users are required to accept the terms of service prior to using the system.
DCF-69	Access Provisioning	Formal, documented access request form/help desk ticket for a recent new hire.
DCF-76	Critical Change Management	For a hot fix or emergency change, upload evidence to show that the change followed the standard change management process (reviews, testing and approval) or that it was reviewed and approved by an authorized individual after implementation. Example: Screenshots or exports of pull requests/merge requests showing change control, documentation such as internal tickets or emails showing post-implementation review and approval, etc.
DCF-91	Intrusion Detection/Prevention System	1. Screenshots from AWS GuardDuty, Azure Sentinel, GCP Security Command Center or equivalent monitoring tool showing that the service is enabled. - and - 2. Screenshots from the mentioned applications/tools/services showing the types of threats that would be detected. - and - 3. Screenshots from the mentioned applications/tools/services showing how personnel would be alerted and who would be alerted when threats are detected.
DCF-98	Backup Storage	Tickets showing that backup failures were monitored and resolved.
DCF-103	Customer Data Deletion Upon Termination	For a recently churned customer, upload evidence showing that customer data disposal was conducted in accordance with the contractual agreements with the customer (such as evidence of logs showing data was disposed of, screenshots from production resources such as storage buckets and databases showing customer-specific resources were decommissioned.). -and- Upload evidence of the agreement with the former customer to show the specific data disposal requirements and commitments.
DCF-107	Disposal of Sensitive Data on Paper	Observation of hard copy material being disposed Note: This can be performed by auditors on-site, or via virtual meeting.
DCF-108	Secure Storage Mechanisms	Pictures of secure storage bins from office locations.
DCF-109	Disposal of Sensitive Data on Hardware	Data Retention Policy or equivalent policy documenting this policy and procedure.
DCF-112	Notice and Acknowledgement of Privacy Practices	Screenshots of the new user registration process where new users are provided the notice of privacy practices before completing the registration process.
DCF-115	Privacy Policy Content	Add a link to your publicly available privacy policy/notice. The privacy policy should contain information including, but not limited to: Purpose for collecting/processing personal information Lawful basis for collecting/processing personal information Types of personal information collected or processed Choice and consent Methods of collection (for example, use of cookies or other tracking techniques) Use, retention, and disposal Data subject rights Use of subprocessors Technical and organizational measure Quality, including data subjects' responsibilities for quality Monitoring and enforcement Additional information may be required in the privacy policy to comply with privacy-specific legislation depending on the relevant jurisdiction. Consult with legal counsel.
DCF-123	Procedures for Information Disposal	Formal, documented data deletion policy.
DCF-126	Personal Information Accessible Through System Authentication	Screenshots of a user modifying their personal information within the application.
DCF-127	Privacy Requirements Communicated to Third parties	Evidence to support that third parties with whom PII is sent to, were provided requirements for how PII should be handled, according to your requirements.
DCF-132	Privacy and Security Requirements in Third-Party Agreements	Executed agreements (such Data Processing Agreements, Business Associates Agreements, Service Provider Agreements) with third parties and vendors that are provided access to personal data.
DCF-135	Notification of Incidents or Breaches	1. Formal, documented breach notification procedures. - and - 2. Breach Notification Template
DCF-136	Use of Subprocessors Communicated	Section from privacy practices on your website showing that 3rd parties that receive PII are listed.
DCF-141	Privacy Inquiries Tracked	1. Screenshots of the incident tracking system used to track users' complaints, inquiries and disputes. - and - 2. Example submitted inquiries, complaints or disputes and evidence that resolution was communicated to the customer and corrective actions were performed, as necessary.
DCF-149	Removable Media Device Encryption	If removable media devices are issued by the company to employees, provide evidence that removable media devices are encrypted.
DCF-150	Data Loss Prevention (DLP) Mechanisms	1. Screenshots of DLP software. - and - 2. Example of emails being blocked when they contain sensitive data
DCF-156	Change Releases Approved	For an example change release, upload evidence showing that the release was approved by authorized personnel prior to deployment to production (e.g., screenshot of a pull request/ticket showing approval for a release candidate by an authorized personnel).
DCF-166	Business Continuity Plan	Upload your Business Continuity Plan
DCF-167	Business Impact Analysis	Upload Business Impact Analysis (Typically part of the business continuity plan).
DCF-174	Telework and Endpoint Devices	Upload copy of Information Security Policy
DCF-186	Data De-identification	1. Data Classification Policy - and - 2. Data Protection Policy
DCF-195	Business Associate Agreements	1. Vendor Management Policy -and- 2. Business Associate Policy -and- 3. BAA template (if not contained within the Business Associate Policy)
DCF-253	Data Secure Disposal	Policies and procedures for data disposal.
DCF-258	Sensitive Authentication Data Secured	For issuers and/or companies that support issuing services and store sensitive authentication data, screenshots of data stores and system configurations showing that the sensitive authentication data is secured.
DCF-265	Separate Encrypted File System Access Management	If disk encryption is used, screenshots of the configurations showing that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).
DCF-286	Proper Encryption Strength	Documented policies and procedures which document implementing the proper encryption strength, per encryption methodology in use. Screenshots showing that encryption methods listed in documented policies and procedures are implemented and other methodologies are not supported.
DCF-287	TLS Enabled during Data Transmission	If TLS has been implemented for encrypting cardholder data during transmission, screenshots showing that TLS has been implemented. Example: For browser based cardholder data transmissions, screenshots showing that HTTPS appears in the URL wherever cardholder data is collected.
DCF-291	Anti-Malware on All System Components	Vendor documentation for all anti-virus software used within the CDE. Screenshots from the anti-virus tools in use to verify that the solutions: Detects all known types of malicious software. Remove all known types of malicious software. Protect against all known types of malicious software. Examples of types of malicious software include viruses, Trojans, worms, spyware, adware, and rootkits.
DCF-292	Periodic Evaluation of Malware Threats	For systems not commonly affected by malicious software, job description of the individuals responsible for evaluating new/emerging malware threats. Screenshots of any tools, group memberships, or mailing lists used to assist in this monitoring.
DCF-293	Anti-Malware Capabilities and Automatic Updates	Screenshots from the anti-virus configurations. including the master installation, showing how the anti-virus and virus definitions are kept current and updated.
DCF-294	Anti-Malware Tools Behavior	Screenshots from the anti-virus configurations. including the master installation, showing that periodic scans are performed.
DCF-297	Patch Management	Lists of patches provided by the vendor for systems within the CDE. Screenshots from systems within the CDE showing that critical security patches have been installed.
DCF-312	Secure Code Development Training	Screenshots or exported training records showing that developers have received secure coding training, including how to avoid common software vulnerabilities, within the last 12 months.
DCF-313	Application Development based on Secure Coding Guidelines	Documented software development policies and procedures which include processes to protect custom developed code from the vulnerabilities.
DCF-334	Privileged and General User ID Authorization	Documented policies and procedures for Identity Management which include processes for controlling the addition, deletion, and modification of user IDs, credentials, and other identifier objects. Documented access authorization for an example administrative/privileged user. Screenshots from the example administrative/privileged user showing that the account has only been assigned the approved permissions. Documented access authorization for an example general/non-privileged user. Screenshots from the example general/non-privileged user showing that the account has only been assigned the approved privileges.
DCF-339	Account Lockout after Failed Logins	For service providers, documented internal processes and customer documentation which state that accounts will be locked out after six unsuccessful authentication attempts. Screenshots of system configurations showing how the account lockout requirement is enforced.
DCF-340	Lockout Duration	Documented policies and procedures related to Identity Management which state a requirement that locked out accounts will remain locked out for no less than 30 minutes or until unlocked by an administrator. Screenshots of system configurations showing how this account lockout duration is enforced.
DCF-382	Security of Offline Media Backup Storage	Documented review of the security of the backup media storage location from the last 12 months.
DCF-390	Media Destruction	Documented policies and procedures related to Media Destruction
DCF-391	Media Destruction Policies and Procedures	Documented policies and procedures related to Media Destruction which includes: Hard-copy materials must be crosscut shredded, incarcerated, or pulped such that they cannot be reconstructed. Storage containers used for storing media awaiting destruction must be secured. Cardholder data stored on electronic media must be disposed of in such a way that it is unrecoverable such as secure deletion or physical destruction of media in accordance with industry standards.
DCF-414	Audit Trail of System-Level Object Changes	Screenshots of audit log settings showing that the creation or deletion of system-level objects are logged. Screenshots of an example log showing that these log settings are functioning correctly.
DCF-438	Follow-up Procedures on Log Review Anomalies and Exceptions	Documented policies and procedures related to Log Review detailing how to follow up on identified anomalies and exceptions found in logs.
DCF-455	Internal Vulnerability Scans	Internal Vulnerability Scans from the past 4 quarters (NOTE: for initial compliance, the past 4 quarters are not required, just the most recent scan). Any supporting documentation from these internal vulnerability scans.
DCF-456	Vulnerabilities Identified and Resolved	Documentation showing that any high-risk items in quarterly vulnerability scans have been remediated. Rescan reports showing that all high-risk items identified in quarterly internal scans have been remediated.
DCF-461	External Vulnerability Scans After Significant Change	Documented policies and procedures which define what constitutes the definition of a significant change. Any documented vulnerability scan results showing that scans are carried out after a significant change within the CDE has occurred.
DCF-469	Resolving Vulnerabilities from Penetration Testing	Documented penetration test reports, retesting reports, and remediation documentation showing that any identified exploitable vulnerabilities were corrected and that testing was repeated until the vulnerabilities were corrected.
DCF-477	IDS/IPS Up to Date	Vendor documentation for the IDS/IPS solution implemented. Screenshots of system configurations showing how the IDS/IPS and signatures are kept up-to-date.
DCF-479	Periodic Critical File Comparisons	1. Screenshots of the alerting configuration for the change detection solution, including who is alerted. 2. Screenshots of the change detection system configuration settings showing that critical file comparisons are carried out at least weekly.
DCF-482	Acceptable Use Policy for End-User Technologies	Documented policies for acceptable use of critical technologies which states that explicit approval from authorized parties is required to use all technologies.
DCF-485	Technology User Tags	Documented policies for acceptable use of critical technologies which states a requirement to tag devices in a way that displays owner, contact information, and purpose.
DCF-507	Vendor Due Diligence	Formally documented policies and procedures for engaging with service providers, including proper due diligence which will be performed on potential service providers.
DCF-516	Incident Response Training	Documented policies or procedures related to Incident Response or Training which include a requirement to train staff with Incident Response roles on a periodic basis.
DCF-528	Management of Sensitive Information	Data Classification Policy as long as it includes: Classification for PII Handling procedures for PII Any Security Awareness Training materials that include information about handling PII and inform end users how to report security issues.
DCF-529	Data Subject Consent	Documentation that details how consent is obtained from Data Subjects prior to processing their PII. Screenshots of automated consent mechanisms that are built into processes that collect PII, such as a consent checkbox on a marketing webinar registration form. Records of where/how consent was obtained, such as records in the CRM system used by marketing and sales.
DCF-536	Record of Processing Activity (ROPA)	Completed ROPA documentation that includes the elements described in Control Activities a-g (Please see Appendix A of Drata’s latest Personal Data Management Policy template for more information on ROPAs). Be sure to consider your processing activities across different Personas, such as Marketing and Sales Prospects, Customers, Website Visitors, Employees, etc. It can be helpful to complete a separate ROPA per Persona. Further guidance on ROPAs can be found here ROPAs are only required in certain circumstances. The Control Activity Note details which circumstances trigger this requirement.
DCF-537	Data Processing Agreements	DPA templates used when sharing PII with third parties (an example DPA has been included in Appendix A of Drata’s latest Vendor Management Policy Template, for reference). Copies of fully executed contracts with third parties that include DPAs.
DCF-540	Timely Response to Data Subject Requests or Inquiries	Records of Data Subject Requests (DSRs) received and the actions taken to resolve them.
DCF-541	Procedures for Management of Data Subject Rights	Privacy Policy that includes information about how Data Subjects can exercise their rights under the GDPR, such as sending an email to a specific company inbox or a web form they can use to make the request. Records of Data Subject Requests (DSRs) received and the actions taken to resolve them. Any internal documentation used to action DSRs, such as documentation that is used to process a ‘Delete My Data’ or ‘Forget Me’ request.
DCF-543	Communication of Changes in Subprocessors	For any recent changes in subprocessors, upload evidence showing that changes were communicated to customers. Examples: Screenshots of email communications sent to notify customers of changes in subprocessors, screenshots of announcements in web page or customer portal, etc.)
DCF-547	Management of Data Subject Rights (Minors)	Upload evidence from your privacy policy showing that it includes specific procedures for managing the data rights of individuals under the age of 16. Examples: Privacy Policy Excerpt: A screenshot or direct copy of the section(s) from your public-facing Privacy Policy that describe the procedures for handling PII and data rights for minors, specifically mentioning parental/guardian consent and how to exercise these rights. Internal Procedures for Minors' Data: The internal playbook or SOP that details how your teams operationally handle and verify data subject requests from, or on behalf of, individuals under 16, consistent with the public policy.
DCF-549	Identity Verification for Data Subject Requests	For one example data subject access request received by the organization, upload evidence showing that verification was done to confirm that the person making a privacy right request is the data subject or an authorized agent. Alternatively, upload your documented procedures to verify the identity of the requestor submitting an data subject request.
DCF-550	Specific Requirements for Managing Data Subject Rights	Upload evidence of your established process for managing data subject requests, including how requests are submitted, responded to, and how users can opt-in or out. Examples: Privacy Policy and User Portals: Screenshots from your Privacy Policy or user-facing portals that describe the methods for submitting requests (e.g., a web form, email address), expected response details, and the procedures for opting in or out of communications or data processing. Internal DSR Handling Procedure: The internal playbook or SOP that guides your teams in processing data subject requests. This document should cover the entire lifecycle, including request intake, identity verification, fulfillment, and required response timelines (SLAs).
DCF-555	Privacy by Design	Upload evidence demonstrating that privacy principles are proactively integrated into the design and architecture of your IT systems and business practices. Examples: Privacy Impact Assessment (PIA) Process: Your documented procedure for conducting PIAs or Data Protection Impact Assessments (DPIAs) for new projects or significant system changes, along with a sample of completed assessment records showing the process in action. Secure Development Lifecycle (SDLC) Policy: The formal policy, standard, or procedure for your SDLC that requires a privacy review as a mandatory step or gate in the development process before systems are deployed.
DCF-557	Shared Account Management	System Access Control Policy
DCF-570	Disciplinary Process	Upload your company's documented disciplinary process. The disciplinary process may be an HR-owned process available and communicated to employees through an employee handbook, code of conduct, or included within an information security policy documentation. Note: This evidence should not be confused with disciplinary procedures for general performance issues or misconduct such as harassment. This specifically pertains to disciplinary actions for breaches of information security policies or violations of security requirements. A formal disciplinary process should outline a graduated response based on factors such as: The nature and severity of the breach (who, what, when, how, and consequences) Whether the violation was intentional (malicious) or unintentional (accidental) Whether it was a first-time or repeated offense Whether the individual received adequate training on the relevant policies The disciplinary response must also account for legal, regulatory, contractual, and business obligations. It should serve not only to address violations but also as a preventive and deterrent measure to discourage future breaches by personnel or other relevant parties. In cases of deliberate violations, immediate actions may be warranted.
DCF-574	Mobile Device Management Software	Upload evidence to show that a Mobile Device Management (MDM) solution has been implemented to enforce security controls on mobile devices. Examples: Screenshots from the MDM’s centralized management console, baseline configuration settings, or enforced security policies/blueprints by device OS type.
DCF-576	System Information and Integrity Policy	Link the System Information and Integrity Policy to the control as evidence. Drata provides a template in your Policy Center.
DCF-637	Secure Development Process	Upload documentation of your organization's secure development processes. Example: Internal wikis, process documents, or guidelines that reference industry standards and best practices for secure development. Documentation should include security requirements (e.g., secure authentication, logging), and demonstrate how information security is considered at each stage of the software development life cycle (SDLC).
DCF-671	External Systems Inventoried	A documented list of external assets (clearly labeled as external), including ownership and location details for each external asset. For cloud infrastructure, screenshots with identification of which assets are externally hosted. Review logs or reports showing periodic updates to the inventory.
DCF-677	Software Update and Patch Management	Upload evidence showing that automated mechanisms have been implemented to install security upgrades to operating systems (e.g., screenshots showing unattended upgrades, apt-get-update / apt-get-upgrades within infrastructure as code configuration files, screenshots of management console for patch management tools such as Automox, etc.)
DCF-707	Credentials for System Accounts Not Hard-Coded	Upload evidence showing that the organization has implemented mechanisms to validate that authentication credentials for any application and system accounts are not hard coded in scripts, configuration/property files, or bespoke and custom source code. Example: Screenshots from source code repositories showing secret scanning is integrated into the CI/CD pipeline.
DCF-712	Static Application Security Testing	Upload evidence that Static Application Security Testing (SAST) is performed as part of the software development process. Example: Screenshots from the CI/CD pipeline showing that SAST scans automatically run on code commits, or screenshots of configurations and dashboards from SAST tools (e.g., SonarCloud, Checkmarx, Veracode).
DCF-716	Application and System Accounts Authorized	Upload company’s access control policies, access request forms or approval tickets, access logs demonstrating privileges align with system needs, signed management approval for provisioning access, and periodic access review records. Examples: Access Control Policies: Upload the company’s access control policies that define the rules and requirements for granting, managing, and reviewing access to systems. Access Request Forms or Approval Tickets: Provide sample access request forms or approval tickets showing how access is requested and approved. Access Logs: Include access logs that show how user privileges align with system needs, ensuring users only have the necessary access. Signed Management Approval: Upload signed management approval records for access provisioning to demonstrate that access was granted with appropriate oversight. Periodic Access Review Records: Provide documentation showing the periodic review of user access, confirming that access privileges are reassessed regularly.
DCF-737	Protected Storage of Secret and Private Keys for Account Data	Upload evidence that cryptographic keys are stored within a certified Secure Cryptographic Device (SCD) and are split into at least two components or shares (e.g., the SCD’s FIPS 140-2/3 certificate and screenshots from the SCD management console showing a quorum or multi-person control policy configured for the keys).
DCF-741	Logging and Monitoring Policy	Logging and Monitoring Policy.
DCF-746	Privacy Training	Upload evidence that a PII protection training program is established and that all personnel complete it upon hire and annually thereafter. Examples: Training Policy and Content: A copy of the formal policy that requires PII training for all personnel, along with the training materials or course outline used. Training Completion Records: Completion reports from your Learning Management System (LMS) for a sample of recently onboarded personnel and for the most recent company-wide annual training cycle.
DCF-750	Data Minimization Objectives	Upload evidence of your documented data minimization objectives and the technical or procedural mechanisms used to achieve them. Examples: Data Minimization Policy or Standard: A copy of the formal policy, standard, or procedure that defines your organization's objectives for minimizing data collection, use, and retention. Technical Implementation Evidence: Architectural diagrams, data flow documentation, or configuration screenshots showing the data minimization mechanisms (e.g., de-identification, tokenization, aggregation) in use within your systems.
DCF-752	Obligations to Data Subjects	Upload evidence that you have documented your legal and regulatory obligations to data subjects and the mechanisms you provide for them to exercise their rights. Examples: Privacy Notice or Policy: A copy of your external-facing Privacy Notice or an internal policy that details the rights afforded to data subjects (e.g., right to access, deletion, correction) under applicable regulations like GDPR or CCPA. Fulfillment Process Documentation: Internal procedure documents (playbooks) for handling data subject requests, or screenshots of the user-facing web portal or form where individuals can submit these requests.
DCF-754	Right to Access	Upload evidence of your documented procedures and implemented mechanisms for fulfilling data subject access requests, including locating, retrieving, and providing PII. Examples: Data Subject Access Request (DSAR) Procedure: A copy of the internal playbook or standard operating procedure (SOP) that details the step-by-step process for handling a request, from data location and retrieval to final delivery to the individual. Completed Request Records: Redacted examples of completed access requests from your ticketing or case management system. This evidence should show the process in action, including internal tasks and the final communication sent to the data subject.
DCF-762	Managing Changes to Supplier Services	For a change to the provision of services by a vendor, provide documentation to evidence that a review and due diligence activities were required and authorized by management Note: Auditors may request a complete population and select samples to verify this control.
DCF-763	Requirements for Protection of Intellectual Property Rights	Upload an example executed agreement addressing confidentiality with recently hired employees (e.g., NDA, PIIA, employment agreement including confidentiality clauses, etc.).
DCF-765	Limit Collection of PII	Upload evidence that optional PII collection and processing is disabled by default and requires explicit, opt-in consent from the user. Examples: User Interface Screenshots: Screenshots of consent points (e.g., account registration pages, privacy dashboards, cookie banners) showing that toggles for optional PII processing are off or checkboxes are unchecked by default before user interaction. Design and Policy Documentation: Excerpts from UX design specifications or the official privacy policy that mandate "privacy by default" and require all optional data processing to be explicitly opt-in.
DCF-768	Personal Data Inventory	A formal, up-to-date inventory of all system components, products, or services that store or process PII. The inventory should include: Category of PII (e.g., financial data, health data, personal identifiers) System Location (e.g., cloud service, on-premises server, database) Data Elements (e.g., name, email, social security number) Data Owner (e.g., department or individual responsible) Data Action (e.g., collection, processing, storage, transfer) Retention Policy (e.g., 3 years, 7 years, until account closure) Other Attributes deemed relevant (e.g., sensitivity level, encryption status)
DCF-770	Consulting with Customer Prior to PII Disclosures	Upload evidence of your process for verifying an authorized agent's permission directly with the data subject before fulfilling a privacy rights request. Examples: Authorized Agent Verification Procedure: The internal playbook or SOP that defines the step-by-step process for confirming an agent's authority directly with the data subject before the request is processed. Completed Verification Records: Redacted examples from your ticketing or case management system for a request submitted by an agent. The evidence should show the communication log of your direct outreach to the data subject and the retained proof of their confirmation (e.g., email response, completed verification form).
DCF-771	Infringing Instruction	Upload evidence of your process for notifying customers when their data processing instructions may infringe on applicable laws, and how you document these notifications.
DCF-772	PII Handling Mechanisms and Policies to Customers	Upload evidence demonstrating that you provide customers with the ability to securely return, transfer, or dispose of their PII, and that you make your data disposal policies available to them. Examples: Customer-Facing Documentation and Tools: Screenshots from your customer knowledge base, user portal, or contractual agreements that show the tools or describe the procedures for exporting (return/transfer) or deleting (dispose) their data. Include a copy of the data disposal policy or documentation you provide to customers. Internal Secure Deletion Procedures: The internal technical SOP or policy that details the secure methods used for data disposal (e.g., cryptographic erasure, degaussing). This document should validate the information and commitments provided to customers.
DCF-782	Cloud Storage Lifecycle	Upload evidence of any cloud storage lifecycle rules in place to delete data automatically after expiration of specified retention periods (e.g., screenshots from cloud storage showing configured expiration actions, etc.).
DCF-785	Supported System Components	1. Asset Management Policy. - and - 2. Screenshots of run configuration standards for in-scope applications and platforms.
DCF-800	AI Governance Policy	Upload evidence of your documented policy for the governance of AI systems, which establishes your requirements for responsible AI practices. Examples: Responsible AI or AI Governance Policy: A copy of the formal, approved policy document that establishes the governance framework, rules, and principles for the development and deployment of AI systems. This policy should cover topics such as fairness, accountability, transparency, and ethics.
DCF-801	AI Risk Management Policy	Upload evidence of your documented policy for managing AI-related risks, including the methodology for how you assess, evaluate, and mitigate those risks. Examples: AI Risk Management Policy: A copy of the formal policy that defines the process for managing AI risks. Completed AI Risk Assessments: A sample of completed risk assessment reports for an AI system that demonstrates the application of the policy's methodology.
DCF-802	AI Feedback Management	Upload evidence of your established process and active mechanisms for collecting feedback on your AI systems from both internal employees and external parties. Examples: AI Feedback Procedure: A copy of the formal procedure that defines the channels and methods for collecting feedback. This document should detail how you manage input from internal stakeholders (e.g., employees via an ethics committee or reporting tool) and external stakeholders (e.g., customers or the public via a website form). Feedback Mechanisms and Logs: Screenshots demonstrating the active and accessible tools used to collect feedback (such as a public-facing "Report an AI Issue" portal or a dedicated email address). Additionally, provide redacted logs or tickets from your tracking system to show that feedback is being received, recorded, and managed according to your procedure.
DCF-803	AI System Opt-Out	Upload evidence of the mechanisms that allow users to opt out of, or contest decisions made by, your AI systems. Examples: AI Appeals and Opt-Out Procedure: The documented procedure or playbook that details how your teams handle user requests to contest an AI decision or opt out of an AI-driven feature. This should include the steps for human review, escalation, and final communication with the user. User-Facing Mechanisms and Case Records: Screenshots of the user-facing tools that allow individuals to contest a decision (e.g., an "Appeal Decision" button after a result is shown) or manage their AI preferences (e.g., an "Opt-Out" toggle in a settings menu). Additionally, provide redacted case records or tickets showing these requests being processed and resolved.
DCF-804	AI Training	Upload evidence that relevant personnel complete Responsible AI training upon hire and annually thereafter. Examples: AI Training Policy and Content: A copy of the policy that requires Responsible AI training for personnel involved in the AI lifecycle. Also include the training materials or course outline to demonstrate the topics covered, such as fairness, accountability, and compliance with your AI policies. Training Completion Records: Completion reports from your Learning Management System (LMS) or other tracking tool. The evidence should include a sample of new hires for onboarding and the summary report for the most recent annual campaign.
DCF-805	AI Committees	Upload evidence that you have formally identified and documented the groups and committees responsible for AI-related feedback and information sharing. Examples: AI Governance Charter or Terms of Reference: A copy of the official charter or policy document that establishes your AI committees or advisory groups. This document should detail the group's purpose, scope, and membership, including internal, external, and expert representation. Committee Meeting Records and Membership Lists: A current membership list for each AI advisory group. Also, provide redacted meeting minutes or agendas from recent meetings to demonstrate that the groups are active and fulfilling their information-sharing and feedback responsibilities.
DCF-806	AI Development and Evaluation Policy	Upload evidence of your documented policy that governs the entire lifecycle of your AI systems, including the practices and roles for ensuring their safe and responsible use. Examples: AI Lifecycle Policy or Standard: A copy of the formal policy or standard that governs the safe design, development, deployment, and evaluation of AI systems. The document should clearly define the practices, roles, and responsibilities for each phase of the AI lifecycle. Design and Evaluation Records: Evidence from your development process showing the policy is followed. This could include design documents with a required "Safety and Ethics Review" section, model evaluation reports, or records from a formal pre-deployment review meeting where the system was assessed against the policy's requirements.
DCF-809	AI Practitioner Proficiency	Upload evidence of your documented process for ensuring and assessing the proficiency of personnel who operate or manage AI systems. Examples: AI Proficiency and Certification Program: The documented program or policy that defines the proficiency requirements for AI operators and practitioners. This should outline the required competencies in AI performance, trustworthiness, and any required technical standards or certifications. Proficiency Assessment Records: Records demonstrating that personnel have been assessed against the proficiency requirements. This could include completed training records, results from competency assessments, or copies of any required certifications held by relevant staff.
DCF-810	Human Oversight over AI Systems	Upload evidence of your documented processes and implementation of human oversight for your AI systems. Examples: AI Human Oversight Procedure: The documented procedure or playbook that defines when and how human intervention or review is required for AI system operations. This should specify the triggers for oversight and the roles and responsibilities involved. Oversight and Review Records: Logs or case files from your operational systems demonstrating that human oversight was performed as required. This could include records of a human approving a high-risk AI recommendation, review logs from an appeals process, or system alerts that were actioned by a human operator.
DCF-811	AI System Fairness and Bias Evaluation	Upload evidence of your documented process for evaluating fairness and bias in your AI systems, along with records of its implementation. Examples: AI Fairness Evaluation Procedure: The documented procedure, standard, or methodology for testing and evaluating AI systems for fairness and bias. This should define the fairness metrics used, the protected attributes considered, and the testing process before and after deployment. Fairness Testing Reports and Mitigation Records: Reports from fairness testing tools or manual evaluations that show the results of bias assessments for an AI model. Also include any records documenting the steps taken to mitigate identified biases, such as data resampling or model retraining.
DCF-812	AI Model Environmental Impact	Upload evidence of your process for assessing and documenting the environmental impact of your AI systems. Examples: Environmental Impact Assessment Procedure: The documented procedure or standard that requires an assessment of environmental impact during the AI system's lifecycle. This should outline the factors considered, such as energy consumption for model training and carbon footprint. Completed Impact Assessment Records: Completed reports for an AI system that document its environmental impact. This could include calculations of estimated energy usage, carbon footprint analysis, or records of decisions made to mitigate the impact (e.g., choosing a more energy-efficient model or a data center powered by renewables).
DCF-813	AI Risk Tracking	Upload evidence of your documented process for tracking emerging and currently unmeasurable risks related to AI. Examples: Emerging AI Risk Tracking Procedure: The documented procedure that outlines how your organization identifies, discusses, and tracks emerging or long-term AI risks. This should describe the sources of information used (e.g., academic research, industry reports) and the forum for discussion (e.g., an AI ethics committee). Emerging Risk Register and Meeting Minutes: A copy of your emerging AI risk register or a similar log that documents the long-term risks being tracked. Also include redacted meeting minutes from the responsible committee or group where these risks were discussed and reviewed.
DCF-814	Security Impact Assessment for Changes	Upload evidence of the documented process for evaluating the security impact of system changes and validating security requirements after implementation. Examples: Change Management Policy/Procedure: A copy of the documented policy or procedure that outlines the process for evaluating the security impact of system changes before implementation. Change Impact Assessment Records: Evidence of completed security impact assessments for system changes, including any findings or recommendations related to vulnerabilities or security risks. Post-Implementation Validation Records: Documentation that confirms security requirements were validated after system changes were implemented, such as validation reports, testing records, or sign-offs by responsible personnel.
DCF-821	Removable System Media Ownership	Upload evidence of your process for assigning ownership to removable media and prohibiting the use of un-owned devices. Examples: Removable Media or Acceptable Use Policy: The documented policy that requires all removable media (e.g., USB drives, external hard drives) to have an assigned owner and prohibits the use of media with no identifiable owner. Removable Media Inventory: A copy of your removable media inventory or log. The log should list each device (e.g., by serial number), its assigned owner (individual, team, or project), and the date of assignment.
DCF-826	Role-Based Security Training	Documented policy outlining the requirements for specialized security training for personnel with security-related duties and procedures specifying when training is required (e.g., before access is granted, after system changes, periodically). Upload records of completed training sessions, including dates, attendees, and training topics.
DCF-832	Review of Agreements and Contracts	For New Agreements (Pre-Execution Review) Process Documentation: A formal Standard Operating Procedure (SOP) defining the mandatory review steps, required reviewers (e.g., Legal, Security), and approval workflow. Execution Record: A completed review checklist for a specific contract, signed and dated by all reviewers before the contract's effective date. Approval Evidence: A saved email chain or a signed memo showing final, explicit approval from all required parties to execute the agreement. For Existing Agreements (Ad-Hoc Review) Process Documentation: A formal policy defining the triggers for conducting an ad-hoc review (e.g., contract renewal, security incident, change in services). Execution Record: A review memo or report for a specific ad-hoc review, detailing the trigger, findings, actions taken, and the date of the review.
DCF-837	Identity Verification for New Personnel	Upload evidence of your process for verifying the identity of new personnel using government-issued credentials and retaining the verification records. Examples: Onboarding or Background Check Policy: The documented HR or security policy that requires identity verification for all new personnel using a government-issued ID during the onboarding process. Completed Verification Records: Redacted records for a sample of new hires confirming that identity verification was completed. This could be a signed onboarding checklist, a background check report summary, or a completed I-9 form. Do not provide copies of the actual IDs.
DCF-877	AI Impact Assessment	Upload evidence of your process for conducting and documenting AI impact assessments that consider consequences to individuals, groups, and society. Examples: AI Impact Assessment Procedure: The documented procedure or methodology for conducting AI Impact Assessments. This should outline the scope, criteria, and process for evaluating the potential consequences of an AI system on individuals, groups, and society. Completed AI Impact Assessment Reports: A sample of completed AI Impact Assessment reports. The reports should document the analysis of potential impacts, consider the specific societal context of the system's use, and outline any mitigation measures for identified risks.
DCF-879	AI Data Management	Upload evidence of your documented process for managing the lifecycle of data used in your AI systems. Examples: AI Data Management Policy or Standard: The documented policy or standard that governs the management of data for AI systems. This should detail the processes for data selection and acquisition, data quality standards, establishing provenance, and data preparation and use. Data Provenance and Quality Records: Documentation for a specific dataset used by an AI model that shows the policy in practice. This could be a "Datasheet for Datasets," a data quality assessment report, or records documenting the data's origin (provenance) and the preparation steps applied before model training.
DCF-176.AI	Measurement and Monitoring Plan (AI)	Upload evidence that you have defined and periodically monitor performance measurements for your AI management system. Examples: AI Governance Metrics and Monitoring Procedure: The documented procedure that defines the performance and effectiveness metrics (KPIs/KRIs) for your AI management system. This document should also specify the frequency and process for collecting and reviewing these measurements. Performance Monitoring Reports: Reports or dashboard screenshots from the most recent review period that show the collected metrics for the AI management system. This could also include meeting minutes from a governance committee where these performance metrics were presented and discussed.
DCF-566.AI	Management of Nonconformities (AI)	Upload evidence of your process for performing root-cause analysis and implementing corrective actions for nonconformities. Examples: Corrective Action Procedure: The documented procedure or policy that outlines the process for handling nonconformities. This should detail the requirements for performing a root-cause analysis (RCA), developing a corrective action plan (CAP), and documenting the results. Completed Corrective Action Records: A completed Corrective Action Report for a recent nonconformity (e.g., from an internal audit finding or security incident). The evidence should include the documented root-cause analysis, the corrective actions assigned, and the final verification that the actions were effective.

Example Evidence for Not Monitored Controls (HIPAA)

Example Evidence for Not Monitored Controls (ISO 27001)

Example Evidence for Not Monitored Controls (SOC 2)

Example Evidence for Not Monitored Controls (CIS 8.1)

Example Evidence for Not Monitored Controls (NIST 800-171 Rev 3)