Example Evidence for Not Monitored Controls (CIS 8.1)

Note: The examples below are illustrative only. Auditors may request additional or alternative forms of evidence based on your scope, risk posture, and implementation details.

DCF Code	CIS 8.1 Safeguards	Name	Example Evidence
DCF-7	16.8	Separate Environments	Upload evidence showing separate environments exist for development, testing, staging, and production as applicable Example: Screenshots of the web environments showing different URLs, screenshots showing separate infrastructure such as different servers, databases, networks for production and lower environments, etc.
DCF-9	16.2, 17.2, 17.3, 17.6,	Internal Communication Channels	Upload examples of internal communication channels for employees to report failures, events, incidents, concerns, and other issues. Example: Screenshot of internal channels dedicated to security event reporting in messaging apps (Slack, MS Teams, etc.), whistleblower channels, etc.
DCF-11	5.1, 6.8, 16.1	Periodic Access Review	Upload documentation of the most recent user access and permissions review. Example: Screenshots of the user lists and permissions reviewed, evidence of sign-offs or approvals by at least two individuals (SOD), documentation of changes requested if any, and evidence that the changes requested were implemented. The scope of the review should be discussed with your auditor as different auditors may have different expectations (based on the scope of the assessment, relevant framework(s), etc.) Auditors will generally require to see the following: - Evidence of the review inputs (what artifacts were reviewed?) such as screenshots of user lists with permissions. - Evidence that segregation of duties was maintained (e.g., two individuals sign-off the review so that no reviewer is approving their own access). - Changes identified were implemented (e.g., tickets documenting removal of accounts, updated user lists showing modifications in permissions, etc.) Auditors would generally expect to see these review activities done at least annually, although quarterly reviews are considered best practice for higher risk systems. Auditors may also expect that the user access review includes a review of physical access rights, if applicable (e.g., reviews of active personnel in the badge system, etc.)
DCF-17	7.2	Risk Treatment Plan	Upload documentation of the most recent risk assessment activities performed (e.g., risk register, risk treatment plan) in accordance with company policies and compliance requirements. The risk assessment drives the selection of controls to be implemented; therefore, a thorough risk assessment is necessary to ensure the selection of controls is appropriate and sufficient to mitigate the risks that threaten the organization's achievement of its goals and objectives.
DCF-20	1.1, 3.2	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-21	12.4	Architectural Diagram	Upload evidence of your current architecture diagram(s) and evidence of updates/reviews within the past year for accuracy (e.g., emails from responsible personnel confirming the accuracy and completeness of the architecture diagram(s), etc.) Architecture diagrams are visual representations of software system components. For additional information and resources visit: AWS: https://aws.amazon.com/what-is/architecture-diagramming/ Azure: https://azurediagrams.com/ GCP: https://cloud.google.com/blog/topics/developers-practitioners/introducing-google-cloud-architecture-diagramming-tool
DCF-22	12.2	Network Diagram	Upload evidence of your current network diagram(s) and evidence of updates/reviews within the past year for accuracy (e.g., emails from responsible personnel confirming the accuracy and completeness of the network diagram(s), etc.)
DCF-26	11.1	Business Continuity/ Disaster Recovery Test	Upload evidence of your most recent business continuity and/or disaster recovery test. Example: Documentation of the activities performed, results, and lessons learned, calendar invites showing participants and dates, etc.
DCF-29	17.1, 17.5	Incident Response Team	Upload evidence of your documented roles and responsibilities for incident response. Example: Documentation of your internal incident response processes and procedures outlining the roles and responsibilities for incident management such as: Incident managers Incident handlers Communication coordinators Advisors
DCF-30	16.3, 17.8	Incident response Lessons Learned	For an example security event deemed an incident, upload the incident documentation including evidence of internal tracking (e.g., internal ticket), root-cause analysis (RCA)/post-mortem, lessons learned, etc.
DCF-56, DCF-132	15.1, 15.4	Vendor Register & Agreements	Upload evidence of an example executed agreement with a vendor or service provider.
DCF-57	15.6	Vendor Compliance Monitoring	1. Screenshots from the vendor directory showing that vendors are categorized based on impact /risk. 2. Review documents showing that vendor due diligence, such as SOC2 reports, ISO 27001 certificates were reviewed (Drata can provide a review template for this).
DCF-61	3.12	Customer Data Segregation	Upload evidence showing customer data is segregated. Example: screenshots from the database showing that unique identifiers are used to associate data to a specific customer, screenshots showing that separate databases/storage buckets are used for individual customers, etc.
DCF-62	4.3	Session Termination	Upload evidence of automated logoff for relevant systems/applications. For example: 1. Screenshots of users being logged out of the application when browser/tab is closed and being forced to re-authenticate upon next login. 2. Screenshots showing that a user is logged out after pre-defined activity timeout and being forced to authenticate upon next login (including application messages, parameters in the application code defining the inactivity period, etc.) Relevant systems may include company-developed web applications and any system or application in use that allows for configuration of automated logoffs. If applicable, discuss scope with your chosen auditor.
DCF-69	6.1, 6.8	Access Provisioning	Upload an example record of access request and approval for a user to be granted permission to a system. Example: Access request ticket with documented approval from system owner or manager, etc. A process to request and approve user accounts and permissions must be in place. Auditors may request evidence of new hire access requests as well as request for changes in permissions to existing users (e.g., transfers, new administrative users, additional permissions to specific resources such as databases or repositories).
DCF-91	13.2, 13.3, 13.7, 13.8	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-92	4.6, 12.3, 12.7	Encrypted Connections for Remote Access	Upload evidence that remote access to production resources is only available through an encrypted connection. Example: Screenshot showing access to production servers or databases is not available if a user is not connected to the internal network via encrypted VPN.
DCF-98	11.3, 11.4	Backup Storage	Provide screenshots or configuration settings from your backup tool (e.g., Azure Backup via Backup Center, AWS Backup) showing that backups are encrypted and stored separately from production; such as in a separate region or in a Recovery Services vault. Additionally, include logs or support tickets (e.g., from Azure Monitor, Jira) that show backup failures were detected and resolved. For example, an alert for a failed backup job and a corresponding ticket documenting its successful retry.
DCF-100	11.1, 11.3, 11.5	Backup Restore Testing	Upload evidence of your most recent test restore of backed-up data completed within the past year. Example: Documentation of the backup restoration process showing steps taken and associated evidence, results, date completed, etc. The evidence should include the steps taken to restore the data from a backup and validation of the completeness and accuracy of the restored data.
DCF-107	3.5	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-109 DCF-253 DCF-390 DCF-619	3.5, 15.7	Disposal of Data on Hardware	Upload evidence for one instance of data disposal on hardware showing that data was disposed securely. Examples: one example certificate of destruction of hardware, screenshots showing that hard drive data on an endpoint were wiped prior to reuse of the device, etc.
DCF-110	16.10	Acceptable Input Ranges	Screenshots of users entering data into the application to confirm that the application limits input values to only valid values.
DCF-111	16.10	Mandatory Fields	Screenshots of user entering data into the application to confirm that the application requires mandatory data to be entered.
DCF-123 DCF-253	3.1, 3.5, 15.7	Procedures for Information Disposal	Upload your documented procedures for erasure or destruction of information that has been identified for disposal.
DCF-135	17.2, 17.3, 17.6	Notification of Incidents or Breaches	For one example security incident or breach, upload evidence showing that notification of the incident or breach was given to affected parties and authorities (as applicable) in accordance with company policies and procedures and contractual and legal obligations.
DCF-149	3.9	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	3.13	Data Loss Prevention (DLP) Mechanisms	Upload evidence of the data leakage prevention (DLP) measures implemented in the organization (e.g., screenshots of DLP rules implemented in corporate email service, configurations from DLP tools in place, etc.)
DCF-154	17.1	Incident Response Test	Upload your recently completed incident response tabletop test.
DCF-155	16.10, 16.12	Testing of Changes	For an example change (e.g., a software update), provide evidence that the change was reviewed, tested in a non-production environment, and approved with appropriate segregation of duties before deployment. Example evidence: Internal ticket showing change requirements, acceptance criteria, and test results Pull request with peer review and approval CI/CD pipeline logs showing tests performed Deployment approval record (e.g., via ticketing or change management system)
DCF-156	16.10	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 authorized personnel).
DCF-166	11.1	Business Continuity Plan	Your Business Continuity Plan.
DCF-168	15.2, 15.7	Vendor Management Policy	Your Vendor Management Policy.
DCF-182	1.2	Asset Management Policy	Your Asset Management Policy.
DCF-187	4.1, 4.2	Configuration Management Plan	Completed Appendix A within the Change Management Policy.
DCF-188	16.2	Communication with Advisor and Special Interest Group	Upload evidence showing that the organization and members of management maintain contact with special interest groups (e.g., security groups, privacy groups, etc.). For example, screenshots or exports showing members of management receive newsletters and updates from professional association groups, email alerts from security advisories such as CISA, participation in conferences, threat advisories, etc.
DCF-190	17.1	Designated Security Officials	Information Security Policy. OR Job description of designated Security Official(s) outlining their responsibility for overseeing the organizations’ compliance with the security rule.
DCF-201	4.2, 4.4, 12.2, 12.3, 12.6, 13.9	Network Security Controls Configuration Standards	1. Formal, documented testing and approval procedures for network connections. 2. Formal documented testing and approval procedures for changes to firewall and router configurations. 3. Example documentation supporting a network connection was tested and approved. 4. Example documentation supporting a recent firewall or router change was tested and approved.
DCF-204	3.8	Dataflow Diagram	Formal Data Flow Diagram including the date the diagram was finalized.
DCF-206	13.4	Network Security Controls Between Trusted and Untrusted Networks	1. Formal, documented firewall and router configuration standards. 2. Screenshots of firewall configurations showing that firewalls are configured in a manner consistent with the Firewall and Router configuration standards.
DCF-210	4.6, 12.6, 13.9	Insecure Services, Protocols, and Ports Documentation and Control	1. Firewall and router configuration standard which documents a list of any insecure Services, Protocols, and Ports used within the environment and controls/security features implemented to mitigate these weaknesses. 2. If Insecure Services, Protocols, or Ports must be used, screenshots showing that documented security features/compensating controls have been implemented for each insecure Service, Protocol, and Port.
DCF-212	4.2, 12.1	Network Security Controls Review	Documented Firewall and Router rule set review from the last 6 months.
DCF-216	13.4	Network Security Controls Restricting Wireless Network Traffic	Provide screenshots of firewall or network access control (NAC) rules showing that wireless traffic is blocked by default. Include configurations or policies demonstrating that only approved wireless traffic is allowed based on business need (e.g., segmented guest Wi-Fi, MAC address restrictions).
DCF-223	3.12	Cardholder Data in Internal Network Zone	1. Internal firewall and router configurations showing that the internal network zone is separate from the DMZ and untrusted networks. 2. Network diagram.
DCF-226	4.5	Personal Firewall Installed on Portable Devices	1. Policies or standard configurations showing that personal firewalls are required on laptops and other portable devices that connect to internal networks or access sensitive systems. 2. Configuration standards for personal firewalls. NOTE - This control covers employee-owned and company-owned devices.
DCF-227	4.5	Personal Firewall on Portable Devices Configured Properly	1. Screenshots showing personal firewalls are configured according to the standard. 2. Screenshots showing personal firewalls installed/active on laptops or other portable devices. 3. Screenshots showing that personal firewalls cannot be disabled and that settings cannot be changed by non-administrative personnel. NOTE - This control covers employee-owned and company-owned devices.
DCF-229	4.7	Vendor Default Accounts Disabled, Removed or Changed	1. Any policy or procedures documenting a requirement stating that ALL vendor supplied default account information must be changed. 2. Screenshots showing that vendor default accounts have been removed, had their default configurations changed, or are disabled.
DCF-233	4.7	Wireless Network Vendor Defaults Changed	1. Any policy or procedures documenting a requirement that All vendor supplied default account information must be changed. 2. Screenshots showing that vendor supplied passwords/passphrases for wireless access points have been replaced.
DCF-240	4.8	Only Necessary System Function Services Used	Screenshots showing enabled services running on in-scope systems, to validate that only approved and necessary services are active.
DCF-244	4.1, 4.2	System Security Parameters in Configuration Standards	Documented Server configuration standards showing that security parameter settings are contained within the standard.
DCF-267	3.9	Sensitive Data on Removable Media Encrypted	1. Screenshots of the configuration to encrypt cardholder data stored on removable media. 2. Screenshots of encrypted cardholder data on removable media. NOTE: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method.
DCF-287	3.10, 12.3	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-288	3.10	Strong Encryption for Wireless Network Transmission	1. List of all wireless networks transmitting sensitive or business-critical data. 2. Documented wireless security standards specifying encryption and authentication requirements. 3. Screenshots of wireless network configurations showing: Use of strong encryption protocols (e.g., WPA2, WPA3) Strong authentication methods (e.g., 802.1X) No use of weak encryption (e.g., WEP)
DCF-291	10.1	Anti-Malware on All System Components	1. Vendor documentation for all anti-malware solutions used across in-scope enterprise systems. 2. Screenshots from the anti-malware tools in use to verify that the solutions: Detect, block, and remove known types of malicious software (e.g., viruses, Trojans, worms, spyware, adware, rootkits) Are configured to provide real-time protection Receive automatic updates to stay current with new threat signatures
DCF-293	10.2	Anti-Malware Capabilities and Automatic Updates	Screenshots from your anti-malware console showing that automatic updates are enabled, detection for all malware types is configured, and threats are set to be blocked, removed, or quarantined. Include settings from the master installation or centralized management view.
DCF-294	10.7	Anti-Malware Tools Behavior	Screenshots from your anti-malware console showing that periodic scans are scheduled and performed, and that real-time protection (e.g., on-access or behavioral scanning) is enabled. Include settings from the master installation or centralized management view.
DCF-297	7.3, 7.7, 16.2	Patch Management	Provide screenshots from in-scope systems showing that critical patches were installed within the required timeframe. Include a reference to your vulnerability or patch management policy that defines patch timelines based on risk.
DCF-301	16.12	Code Review prior to Release	1. Documented SDLC policy or procedures which document the following requirements: Code changes are reviewed by someone other than the original code author. Code reviews ensure that code is developed according to secure coding guidelines. Appropriate corrections are implemented prior to release. 2. Documentation for an example code change to show that the documented review procedures were followed and that code review results are reviewed and approved by management prior to release.
DCF-312	16.9	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	16.1, 16.12	Application Development based on Secure Coding Guidelines	Provide documented software development policies and procedures that include secure coding guidelines and processes to identify and mitigate common code vulnerabilities (e.g., input validation, authentication flaws, injection attacks).
DCF-324	16.1	Public-Facing Web Application Vulnerability Assessment	1. If public-facing web applications exist, provide documented policies or procedures requiring web application security assessments to be performed: At least annually After significant changes By qualified personnel or a third party specializing in application security With guidance to identify, risk-rank, correct vulnerabilities, and reassess the application after remediation Include screenshots or reports showing completed assessments and remediation actions. OR 2. Provide screenshots from the web application firewall (WAF) or automated solution that detects and prevents web-based attacks. Screenshots should demonstrate that the solution: Sits in front of public-facing web applications Is actively running and kept up to date Is generating audit logs Is configured to either block attacks or generate alerts that are promptly investigated
DCF-326	3.3, 6.8	Need-to-Know Principle	Provide documented System Access Control policy that include: Defined access needs and privilege levels by role Processes for enforcing least privilege for system and administrative access Criteria for assigning access based on job function or classification Approval workflows showing that all access is reviewed and approved by authorized personnel, with privileges explicitly documented
DCF-327	6.8	System Access Roles Defined	Documented access needs for each role within the environment which includes: System components and data resources required for the job function. Level of privilege required for accessing resources (user, administrator, etc.)
DCF-329	6.7, 16.10	Access Control System	Screenshots from the access control system for all system components.
DCF-330	6.8	Access Control Model	Screenshots showing how the access control system(s) are configured to enforce privilege assignments to individuals based on job classification.
DCF-339, 340	4.10	Account Lockout after Failed Logins, Lookout Duration	Upload evidence of the account lockout configurations after failed login attempts for relevant systems where this is a configurable attribute, showing number of attempts that trigger the lockout and lockout duration. Not every relevant system will offer this as a configurable attribute. Relevant systems may include cloud infrastructure provider, code repositories, identity provider, password vault systems, VPN clients, systems with stored customer data (e.g., database as a service), and others based on the scope of the engagement. Discuss scoping with your chosen auditor.
DCF-352	5.2	Unique First-time Passwords With One-Time Use	Upload evidence showing that for organization systems passwords are set to a unique value for first-time use and upon reset and temporary initial passwords are forced to be changed immediately after the first use. Example: Screenshots of system configurations or screenshots from a walkthrough of the password reset process.
DCF-354	6.5	MFA for Non-Console Admin Access	1. Provide screenshots of system or network configurations showing that multi-factor authentication (MFA) is enforced for all non-console administrative access to in-scope systems. 2. Screenshots of the authentication process for non-console administrative access to confirm that multi-factor authentication was enforced.
DCF-355	6.4, 13.5	MFA for Remote Network Access	1. Provide screenshots of system configurations showing that multi-factor authentication (MFA) is enforced for all remote access to the organization’s network and systems — including access by users, administrators, and third-party vendors. 2. Screenshots of the authentication process showing that MFA is required for remote network access for both a non-administrative and administrative user.
DCF-356	14.3	Communication of Authentication Best Practices	1. Screenshots showing where employees can find policies and procedures related to Authentication. 2. Documented policies and procedures related to Authentication which include the following: Guidance on selecting strong authentication credentials. Guidance for how users should protect their authentication credentials. Instructions to not use previously used passwords. Instructions stating to change a password if the password is suspected to be compromised
DCF-361	3.3	Direct Access to Database Restrictions	Screenshots of database access control settings and database application configuration settings showing that user direct access to or queries of databases are restricted to database administrators.
DCF-408	16.11	Audit Trail for Individual User Access to Cardholder Data	1. Screenshots of audit log settings showing that individual user access to cardholder data is logged. 2. Screenshots of an example log showing that these log settings are functioning correctly.
DCF-409	16.11	Audit Trail for Root Admin Privilege Access	1. Screenshots of audit log settings showing that all actions taken by root/admin users will be logged. 2. Screenshots of an example log showing that these log settings are functioning correctly.
DCF-410	16.11	Audit Trail Access Logging	1. Screenshots of audit log settings showing that all access to audit trails/logs is logged. 2. Screenshots of an example log showing that these log settings are functioning correctly.
DCF-411	16.11	Audit Trail for Invalid Access Attempts	1. Screenshots of audit log settings showing that invalid/failed login attempts are logged. 2. Screenshots of an example log showing that these log settings are functioning correctly.
DCF-412	16.11	Audit Trail for Identification and Authentication Mechanism Changes	1. Screenshots of audit log settings showing that the use of identification and authentication mechanisms are logged, elevation of privileges are logged, and that changes (addition, modification, or deletion) to accounts with administrator or root privileges are logged. 2. Screenshots of example logs showing that these log settings are functioning correctly.
DCF-413	16.11	Audit Trail of Changes to Audit Logs	1. Screenshots of audit log settings showing that the initialization of logging and stopping or pausing of logging are logged. 2. Screenshots showing that these log settings are functioning correctly.
DCF-414	16.11	Audit Trail of System-Level Object Changes	1. Screenshots of audit log settings showing that the creation or deletion of system-level objects are logged. 2. Screenshots of an example log showing that these log settings are functioning correctly.
DCF-415	8.5	Audit Trail Entries: User Identification	Screenshots of an example log showing that user IDs are captured within log entries.
DCF-416	8.5	Audit Trail Entries: Event Type	Screenshots of an example log showing that the type of event which occurred is captured within log entries.
DCF-417	8.5	Audit Trail Entries: Date and Time	Screenshots of an example log showing that a date and time are associated with log entries.
DCF-419	8.5	Audit Trail Entries: Origination	Screenshots of an example log showing that the source of the event (IP address or similar source) are captured within log entries.
DCF-420	8.5	Audit Trail Entries: Affected Item Name	Screenshots of an example log showing that affected item/resource ID or name is captured within log entries.
DCF-421	8.4	Clock Synchronization	1. Provide documented procedures for time synchronization across in-scope systems, showing that: A designated central time server (e.g., NTP) is used Systems are configured to sync time only from this central server 2. Provide screenshots from system configurations (e.g., server settings, NTP client configs) showing time synchronization is enabled and actively referencing the central time source.
DCF-422	8.4	Time-related System Parameters	1. Screenshots showing that the documented process has been implemented (for example, that NTP has been configured and is being used by system components to synchronize time). Screenshots should show that: Time signals are received in UTC or International Atomic Time. When there is more than one central time server, these time servers are configured to peer with one another. The system may only receive synchronization information from designated central time server(s).
DCF-423	8.4	Time Server Peering	1. Screenshots showing that the documented process has been implemented (for example, that NTP has been configured and is being used by system components to synchronize time). Screenshots should show that: When there is more than one central time server, these time servers are configured to peer with one another.
DCF-434	8.1	Policies and Procedures for Logging	1. Documented policy related to Log Review which states that the following items will be reviewed at least daily: All security events. Logs of all system components that store, process, or transmit sensitive data or perform critical business functions. Logs from all critical system components. Logs of all servers and system components that perform security functions.
DCF-435	8.11	Critical System Logs Reviewed Daily	1. Screenshots showing the process for reviewing the following logs at least daily: All security events. Logs of all system components that store, process, or transmit sensitive data or perform critical business functions. Logs from all critical system components. Logs of all servers and system components that perform security functions.
DCF-437	8.11	Non-critical System Review Aligned with Risk Management	Documented risk assessment which details risks present for non-critical systems.
DCF-440	8.1	Policy for Audit Log Retention	Documented policy related to Audit Log Retention.
DCF-441	8.10	Audit Log Retention Period	1. Documented policy related to Audit Log Retention which states a requirement that logs will be retained for at least 1 year. 2. Screenshot showing that logs, archives or logs, or compressed log files are stored for at least one year.
DCF-444	13.1	Critical Security Control System Failure Alert	1. Screenshots showing how alerts are configured for the following systems: Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used)
DCF-455	7.5	High Risk Vulnerabilities Identified and Resolved	1. Internal Vulnerability Scans from the past 4 quarters (NOTE: for initial compliance, the past 4 quarters are not required, just the most recent scan). 2. Any supporting documentation from these internal vulnerability scans.
DCF-456	7.7, 16.2	Critical Security Control System Failure Documentation	1. Documented records showing that security control failures were documented and that they include the following elements: Identification of causes(s) of the failure, including root cause. Duration (date and time start to end) of the security failure. Details of the remediation required to address the root cause.
DCF-464	18.1	Penetration Testing Methodology	1. Documentation which defines the methodology used for conducting penetration tests which must include: Being based on an industry-accepted penetration testing approach (such as the MITRE attack framework, Cyber Kill Chain, etc.) Includes coverage for the entire CDE perimeter and critical systems. Includes testing from both inside and outside the network. Includes testing to validate any segmentation and scope reduction controls. Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in PCI DSS Requirement 6.5. Defines network-layer penetration tests to include components that support network functions as well as operating systems. Includes review and consideration of threats and vulnerabilities experienced in the past 12 months. Specifies retention of penetration testing results and remediation activities.
DCF-465	18.2	External Penetration Testing Scope	1. Scope of Work from the most recent external penetration test which defines: That the test will be completed using the approved methodology. Will be conducted at least annually. Will be conducted after any significant changes to the environment. 2. Documented penetration test report from the most recent external penetration test.
DCF-467	18.5	Internal Penetration Testing Scope	1. Scope of Work from the most recent internal penetration test which defines: That the test will be completed using the approved methodology. Will be conducted at least annually. Will be conducted after any significant changes to the environment. 2. Documented penetration test report from the most recent internal penetration test.
DCF-469	7.7, 18.3, 18.4	Resolving Vulnerabilities from Pen 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	12.1	IDS/IPS Up to Date	1. Vendor documentation for the IDS/IPS solution implemented. 2. Screenshots of system configurations showing how the IDS/IPS and signatures are kept up-to-date.
DCF-504	14.2, 14.3, 14.4, 14.5, 14.6, 14.7, 14.8	Cardholder Data Security Awareness Training	Training records showing that all personnel have received training upon hire and at least annually thereafter on cardholder data security.
DCF-507	15.5, 16.5	Pre-Agreement Process for Service Providers	Formally documented policies and procedures for engaging with service providers, including proper due diligence which will be performed on potential service providers.
DCF-510	15.4	Service Providers Acknowledge Security Responsibilities (Service Providers Only)	If your organization is a service provider, formally documented policies and procedures which require that your organization acknowledge within a written agreement your responsibilities with maintaining all applicable PCI DSS requirements to the extent that you possess or otherwise store, process, or transmit cardholder data on behalf of your customers or could otherwise impact the security of your customer’s cardholder data environment.
DCF-522	10.4	Anti-Malware Scans of Media	Upload evidence showing that the implemented anti-malware solution is configured to perform automatic scans or continuous behavioral analysis of systems or processes when removable electronic media is inserted, connected, or logically mounted within the environment. Example: Screenshots showing configuration settings from the anti-malware system showing settings for anti-malware scans of media.
DCF-524	5.1, 6.8	Period Review of Application and System Accounts	Upload documentation showing records of periodic reviews of application and system accounts, including dates and details of each review. This should outline the accounts reviewed, associated privileges, and any changes made, such as access modifications or account removals. Example: Review Logs: Logs documenting the accounts reviewed, their privileges, and any changes made. Meeting Minutes or Reports: Minutes or reports from meetings or system administrators confirming review details. Change Request Forms/Approval Records: Forms or records showing how changes were approved and implemented.
DCF-528	3.1, 3.7	Management of Sensitive Information	1. Formally documented policies and procedures for identifying, storing, transferring, and disposing of sensitive information, including secure handling of physical media. 2. Establish and implement procedures for the secure handling of media and storage devices where sensitive information will be kept; log related activities. 3. Evidence of personnel training on handling sensitive information.
DCF-558	2.2, 2.5	Restrictions on Software Installation and Execution	1. Screenshots from an MDM tool or endpoint device configurations showing that software applications are whitelisted (explicitly allowed). 2. Screenshot showing that installation of an application not on the approved whitelist has failed for an example endpoint device.
DCF-566	16.3	Management of Nonconformities	Provide evidence that your organization effectively manages nonconformities. This includes identifying the issue, performing a root-cause analysis, implementing corrective actions, and retaining documentation of the process and outcomes. Examples: Nonconformity Tracker: A centralized log or spreadsheet that tracks identified nonconformities, their status, and resolution steps. Internal Tickets: Support tickets or incident records documenting the discovery, investigation, and correction of nonconformities. Root-Cause Analysis Reports: Documentation showing analysis performed to identify the underlying cause of each nonconformity. Corrective Action Plans: Evidence of actions taken to address the root cause and prevent recurrence. Follow-up and Verification Records: Reports or logs verifying the effectiveness of corrective actions taken. Audit Findings and Resolutions: Documentation of findings from internal or external audits and their resolution status.
DCF-569	3.1, 3.7	Information Labeling	Data Protection Policy and Data Classification Policy.
DCF-574	4.11	Mobile Device Management Software	Upload evidence to show that a mobile device management (MDM) tool has been implemented to enforce security controls on mobile devices (e.g., screenshots from the MDM's centralized management console, screenshots of baseline configurations, security policies or blueprints enforced on devices per OS type, etc.)
DCF-579	5.1, 5.6, 6.1, 6.2	Automated Access Management System in Place	1. Upload documentation outlining how accounts are created, modified, monitored, disabled, and removed. 2. Screenshots or logs from IAM tools (e.g., Okta, Azure AD) showing automated account management. 3. Provide records of account changes with timestamps and monitoring reports. 4. Provide evidence of periodic reviews and automated disabling of inactive accounts. 5. Documentation of access reviews and corrective actions taken if issues are found.
DCF-580	15.7	Disabling High Risk User Accounts	1. System Access Control Policy. 2. Records showing when accounts were disabled, including dates and duration.
DCF-597	4.1, 4.2	Baseline Configurations	1. Upload documentation of how baseline configurations are defined, maintained, and updated. 2. Provide evidence that automated tools are actually being used to enforce and validate baseline configurations (e.g., configuration management reports, automation logs). 3. Provide evidence of real-time monitoring to catch any drift or unauthorized changes.
DCF-637	16.1	Secure Development Process	Upload documentation of your organization's secure development processes. Example: Internal wikis or other documentation that includes references to industry standards and/or best practices for secure development, security requirement considerations (for example, secure authentication and logging, etc.), and consideration of information security issues during each stage of the software development life cycle.
DCF-638	12.8	Separation of User and System Management Functions	1. System documentation (including system components and services). 2. Documented procedures for obtaining, protecting, and distributing system documentation.
DCF-653	9.6	Spam Protection	1. Link your System and Information Integrity Policy to the control as evidence. 2. Screenshot of mechanism(s) in place to protect against spam.
DCF-671	2.1	External Systems Inventoried	1. A documented list of external assets (clearly labeled as external), including ownership and location details for each external asset. 2. For cloud infrastructure, screenshots with identification of which assets are externally hosted. 3. Review logs or reports showing periodic updates to the inventory.
DCF-675	10.3	Auto-run Disabled	1. Documented policy outlining the requirement to disable auto-run features for security purposes. 2. Screenshots or configuration settings from operating systems (e.g., Windows Group Policy settings, macOS configuration profiles) showing that auto-run is disabled. 3. Logs or monitoring reports verifying that auto-run features are disabled and not re-enabled.
DCF-676	4.10	Brute-force Mitigation	1. Documented policy outlining login throttling and device locking requirements, including limits on failed attempts and lockout durations. 2. Screenshots from IAM solutions (e.g., Okta, Azure AD), server configurations, or endpoint management tools showing: Throttling settings (e.g., increasing wait times after each failed attempt). Device lockout settings after 10 unsuccessful attempts. 3. Access logs demonstrating enforcement of throttling and device locking during failed login attempts. 4. Monitoring Reports validating no more than 10 guesses in 5 minutes are allowed.
DCF-677	7.3	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-681	14.2	Phishing Simulations	Upload evidence showing phishing simulations are conducted as part of the company's security awareness initiatives. Example: Screenshots from phishing simulation campaign configurations, screenshots of dashboards showing results of the campaign, screenshot showing example simulated phishing email, etc.
DCF-687	9.5, 9.7	Email Protection Mechanisms	Upload evidence showing that phishing and spam detection mechanisms have been implemented in your organization. Example: Screenshots showing SPF, DMARC, DKIM configurations enabled for email authentication.
DCF-689	17.6	On-Call Team	Upload evidence of on-call rotation schedule. Example: Screenshots from tools like PagerDuty or equivalent tool showing on-call schedule and teams assigned.
DCF-692	3.5, 15.7	Secure Erasure of Temporary Data	1. Documented policy specifying data retention periods and procedures for securely disposing of temporary files, log data, and memory data when no longer needed. 2. Screenshots or settings from automation tools (e.g., AWS S3 Lifecycle Policies, Windows Task Scheduler, Linux Cron Jobs) that handle the scheduled deletion of temporary files and logs. 3. Logs demonstrating regular deletion of temporary data, along with timestamps for verification. 4. Reports confirming the secure disposal of data according to the retention schedule.
DCF-695	3.5	Access to Data on Pre-used Data Storage Space	1. Documented policy outlining the requirement to securely wipe or render unreadable any data on pre-used storage before re-assignment and procedures specifying the wiping methods used (e.g., data shredding, degaussing, cryptographic erasure). 2. Screenshots or configuration settings from tools (e.g., Blancco, DBAN, AWS EC2 Instance Store) that enforce automated data wiping before re-use. 3. Logs demonstrating successful completion of data wipes, including timestamps and confirmation of data destruction. 4. Reports validating that data is rendered unreadable before storage is re-assigned.
DCF-698	8.9, 8.11, 13.1	Automated Mechanism for Audit Log Reviews	Upload evidence to demonstrate that your organization has implemented automated mechanisms for audit record reduction and log analysis. Examples: System Configuration Documentation: Documentation for your SIEM or log management platform showing how automated log reduction and correlation are configured. Log Management System Reports: Reports from your log management system demonstrating automated log reduction and correlated event analysis.
DCF-706	3.12	Multi-Tenant Segregation Between Provider and Customer	Provide documentation showing that logical separation is implemented for multi-tenant service providers. Examples: Network Diagrams: Diagrams illustrating the logical separation of networks and systems for each tenant, showing isolated environments. Access Control Policies: Policies or access control lists (ACLs) that detail how tenants are restricted from accessing each other’s environments, including role-based access controls (RBAC). Configuration Settings: System or network configuration files that demonstrate technical controls (e.g., VLAN configurations, firewall rules) enforcing logical separation between tenants.
DCF-708	2.1, 2.2, 16.4	Software and Third Party Libraries Inventory	Upload evidence of your organization's software and third party libraries Inventory (i.e., software bill of materials). Example: Screenshots from software composition analysis tools showing software bill of materials (SBOM).
DCF-712	16.1, 16.12	Static Application Security Testing	Upload evidence that static application security testing (SAST) is conducted for software development testing. Example: Screenshots from the CI/CD pipeline for relevant code repositories showing a SAST scan automatically executes every time new code is committed, screenshots of configurations and dashboards from SAST tools such as SonarCloud, etc.
DCF-716	6.1	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-730	4.5	Security Controls on Devices that Connect to the Internet	Evidence: Security Control Inventory: Upload a document (e.g., a spreadsheet or list) showing all active security controls such as firewalls, endpoint protection software, and any other relevant security measures. Configuration Settings: Provide screenshots or configuration files that demonstrate the security controls are configured and active on both company- and employee-owned devices. Logs: Include logs that verify the application of these security controls across the devices, confirming they are being enforced properly.c
DCF-741	8.1	Logging and Monitoring Policy	Upload Logging and Monitoring Policy.
DCF-744	17.2, 17.6	Contact with Authorities	Upload evidence of incident response procedures/playbooks or documented communication plans showing that your organization has identified and documented authorities to be contacted (such as law enforcement, regulatory bodies, supervisory authorities) as well as the events or circumstances that would require communication and the methods and responsibilities for communication with authorities. Maintaining such contacts can be a requirement to support information security incident management or the contingency planning and business continuity processes. Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization.
DCF-768	3.2	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-777	3.7	Cloud Resource Tagging	Inventory listing with tags assigned
DCF-780	9.2	Web Filtering	Upload evidence showing that the organization has implemented web filtering mechanisms to enforce the company's internet usage policies (e.g., screenshots of web filtering configurations showing access to known malicious sites are blocked, access to prohibited web resources per the company's acceptable use policy is prohibited, etc.)
DCF-782	3.1	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-784	16.1, 16.2, 16.5	Software Composition Analysis (SCA)	Upload evidence to show that your organization checks software components and libraries for policy and license compliance, security risks, and supported versions. Example: Screenshots showing that software composition analysis tools are used as part of your CI/CD pipeline to check for vulnerabilities in third party libraries.
DCF-785	9.1, 12.1, 16.5	Supported System Components	1. Asset Management Policy. 2. Screenshots of run configuration standards for in-scope applications and platforms.
DCF-788	3.2	CUI Data Inventory	A formal, up-to-date inventory of all system components, products, or services that store or process Controlled Unclassified Information (CUI). The inventory should include: Type of Data (e.g., financial, medical, legal). System Location (e.g., cloud storage, on-premises server, application database). Data Elements (Metadata) (e.g., labels, classification, creation date). Access Controls (e.g., role-based access, encryption status). Other Attributes as defined by your organization (e.g., sensitivity level, data owner).
DCF-793	5.4, 12.8	Dedicated Accounts or Roles for Admin Functions	1. Documented policy and procedure requiring the use of separate, dedicated administrator accounts for administrative or security functions and how standard accounts are restricted from elevated privileges. 2. Access control logs demonstrating that administrative activities are only performed with dedicated admin accounts. 3. Evidence that standard user accounts are not used for privileged activities. 4. Screenshots from your IAM tools (e.g., Okta, Azure AD, AWS IAM) showing separate admin and standard user role configurations.
DCF-799	12.1	Organizational Systems Maintenance	1. Maintenance Management Policy 2. Maintenance logs that show maintenance activities, including the date, component type, and actions taken (e.g., firmware updates, vulnerability patches, software upgrades). 3. Maintenance reports confirming completion of maintenance tasks as per the documented schedule.
DCF-814	16.1	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-820	5.2	Password Minimum Change of Characters	1. Password Policy 2. Screenshots from identity management tools (e.g., Okta, Azure AD, Windows Group Policy) showing password policy settings that enforce character change requirements.
DCF-822	13.5	Remote Access Management	1. Documented policy outlining usage restrictions, configuration standards, and connection requirements for all types of remote access (e.g., VPN, RDP, SSH) and procedures that specify how remote access is granted, monitored, and revoked. 2. Screenshots from VPN configurations, firewall settings, or remote desktop services showing enforcement of connection requirements and multi-factor authentication (MFA) for remote access, if applicable. 3. Access logs demonstrating remote access sessions, including connection times, source IP addresses, and user authentication. 4. Monitoring reports indicating any unauthorized or suspicious remote access attempts.
DCF-826	14.9, 16.1	Role-Based Security Training	1. 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). 2. Upload records of completed training sessions, including dates, attendees, and training topics.
DCF-829	13.6	Network Traffic Monitoring	1. Screenshots or configurations from SIEM tools (e.g., Splunk, Graylog, AWS CloudTrail) or firewall settings demonstrating real-time monitoring. 2. Log samples showing inbound and outbound traffic, flagged alerts, and actions taken. 3. Documentation of incidents where unauthorized or suspicious traffic was detected and addressed with remediation steps taken.
DCF-830	16.14	Threat Modeling	1. Documented policy outlining the requirement for periodic or event-driven threat modeling activities and procedures describing how threat modeling is conducted, including identification of use cases, threat agents, attack vectors, and risk mitigation strategies. 2. Copies of completed threat modeling assessments that include: Use Cases: Documented scenarios of how systems are used and where vulnerabilities may exist. Threat Agents: Identification of potential attackers (e.g., insiders, hackers, nation-states). Attack Vectors: Pathways through which threats could exploit vulnerabilities. Risk Mitigating Factors: Controls or measures in place to reduce risk. 3. Provide evidence showing that threat models are reviewed and updated periodically or when significant changes occur in the environment.
DCF-835	11.5	Asset Integrity Verification Before Restoration	1. Documented policy outlining the process for verifying the integrity of assets (e.g., backups, system images) before they are used in recovery or restoration and procedures specifying how integrity checks are performed and logged. 2. Logs demonstrating completed integrity checks, including indicators of compromise, file corruption, and other issues, along with timestamped records verifying the process before assets are restored or used in incident recovery. 3. Reports or screenshots from backup solutions (e.g., Veeam, AWS Backup, Datto) showing successful verification of backup integrity. 4. Evidence of routine testing to validate that backups are complete, uncorrupted, and uncompromised.
DCF-838	13.5	Endpoint Security Posture Validation	1. Documented policy outlining requirements for endpoint health checks and device posture validation before accessing production resources. 2. Screenshots or settings from endpoint management tools (e.g., Microsoft Intune, Jamf, CrowdStrike) showing enforced health checks (e.g., antivirus status, OS patching, encryption). 3. Logs demonstrating posture checks are performed before granting access.
DCF-839	16.5	Verification of Software	1. Documented policy specifying requirements for verifying the authenticity and integrity of software artifacts before installation or use and procedures for cryptographic verification (e.g., digital signatures, hash comparisons). 2. Logs showing software artifacts were verified for authenticity and integrity before deployment. 3. Evidence of digital signature checks, hash validation, or integrity scans.
DCF-840	3.2	Data Inventory	1. A formal, up-to-date inventory of all data types of interest (e.g., PII, PHI, financial data, intellectual property). The inventory should include: Data Type (e.g., PII, PHI, financial data) Data Owner Classification (e.g., confidential, restricted) Location (e.g., cloud storage, on-premises server, database) Other Relevant Attributes (e.g., encryption status, retention policy) 2. Logs or reports demonstrating periodic inventory reviews, updates, and evidence of automated discovery scans or manual audits.
DCF-847	15.6	Vendor Risk Assessment	1. A documented Vendor/Third-Party Register, including: Vendor Name Relationship Owner Service Description Risk Ratings Results of Risk Assessments You can also leverage your Vendors tab in Drata for this. 2. Executed agreement/contract between the entity and key vendors.
DCF-849	15.7	Exit Strategies for Supplier Relationships	Vendor Management Policy.
DCF-872	17.9	Incident Classification	Incident Response Plan.
DCF-885	1.3	Active Discovery Tool Deployment	1. Policies outlining the use of active discovery tools for asset identification and network visibility. 2. Screenshots from the discovery tool (e.g., Nessus, Qualys, Rapid7) showing: Active scanning schedules (at least daily). Network ranges being monitored.
DCF-886	1.4	DHCP Logging and IP Address Management	1. A documented policy outlining the use of DHCP logging and/or IPAM tools to track and update the asset inventory and procedures specifying log review frequency (at least weekly) and update processes. 2. Screenshots from DHCP servers or IPAM tools (e.g., Infoblox, SolarWinds) showing: Logging is enabled. Active tracking of IP addresses and associated assets.
DCF-887	1.5	Passive Network Discovery for Asset Inventory Management	1. A documented policy specifying the use of a passive discovery tool for continuous asset identification and procedures for reviewing scan results and updating the asset inventory at least weekly. 2. Screenshots from the passive discovery tool (e.g., Darktrace, ExtraHop, ARP monitoring) showing continuous monitoring and scheduled scans. 3. Reports of scan results demonstrating asset detection and visibility
DCF-888	2.3	Record of Unauthorized Software	1. A documented policy outlining the identification, removal, or exception process for unauthorized software and procedures for requesting and approving exceptions if unauthorized software is permitted. 2. Screenshots or reports from software asset management tools (e.g., SCCM, JAMF, Lansweeper) showing: Detected unauthorized software. Removal activities or documented exceptions.
DCF-889	2.4	Automated Software Inventory Tool is Utilized	1. A documented policy specifying the use of software inventory tools for automated discovery and documentation of installed software. 2. Screenshots or reports from software inventory tools (e.g., SCCM, JAMF, Lansweeper) showing automated software detection across enterprise assets. 3. Evidence that the inventory is maintained and updated regularly.
DCF-890	2.6	Authorized Libraries Allowlist	1. A documented policy specifying the use of technical controls (e.g., allowlisting) to restrict system processes to authorized software libraries (.dll, .ocx, .so, etc.) and procedures for bi-annual reassessment of the allowlist. 2. Screenshots or configuration settings from security tools (e.g., Microsoft AppLocker, Windows Defender Application Control, CrowdStrike) demonstrating allowlisting enforcement. 3. Logs of blocked unauthorized libraries attempting to load.
DCF-891	2.7	Authorized Scripts Allowlist	1. A documented policy outlining the use of technical controls (e.g., digital signatures, version control, allowlisting) to restrict script execution to authorized scripts (.ps1, .py, etc.) and procedures for bi-annual reassessment of the script allowlist. 2. Screenshots or configuration settings from security tools (e.g., Microsoft AppLocker, PowerShell Constrained Language Mode, AWS Lambda Policies) demonstrating enforced allowlisting. 3. Logs showing successful execution of authorized scripts and prevention of unauthorized ones.
DCF-892	4.9	Trusted DNS Server Configuration	1. A documented policy outlining the requirement to configure trusted DNS servers on all network infrastructure and procedures specifying the use of enterprise-controlled or reputable external DNS servers. 2. Screenshots or configuration settings from network devices (e.g., routers, firewalls, DNS servers) showing the use of trusted DNS addresses. 3. Evidence of configurations pointing to enterprise-controlled or known secure DNS providers (e.g., Google Public DNS, Cloudflare, OpenDNS).
DCF-893	4.12	Separate Enterprise Workspaces on Mobile End-User Devices	1. A documented policy outlining the requirement to separate enterprise applications and data from personal ones on mobile devices and procedures describing how mobile workspace segregation is enforced. 2. Screenshots or settings from MDM solutions (e.g., Microsoft Intune, VMware Workspace ONE, MobileIron) demonstrating the creation of separate workspaces. 3. Evidence of containerization or workspace isolation for corporate apps and data.
DCF-894	5.5	Service Account Inventory and Review	1. A complete, up-to-date list of all service accounts, including: Department Owner Last Review Date Purpose of Each Service Account 2. Logs demonstrating that service account reviews are performed at least quarterly or more frequently as required. 3. Evidence of checks for authorization, necessity, and compliance with security policies.
DCF-895	6.6	Annual Review of Authentication and Authorization Systems	Upload evidence of the process for performing an annual review of authentication and authorization systems across enterprise environments. Examples: Review Policy or Procedure: A documented policy or SOP that defines the schedule, scope, and responsibilities for annually reviewing authentication and authorization systems (e.g., identity providers, access controls, MFA configurations). Access Review Reports: Reports or exports showing user access rights, group memberships, privileged accounts, and role assignments reviewed during the annual audit. Audit Logs or System Reports: Evidence from identity systems (e.g., Active Directory, Azure AD, Okta) showing login events, access attempts, and policy changes reviewed during the audit. Review Meeting Records or Sign-Offs: Meeting minutes, sign-off forms, or tickets showing review completion, participants, and findings. Remediation Logs: Documentation of changes made as a result of the review, such as removed access, privilege adjustments, or account deactivations.
DCF-896	8.3	Logging System, Log Management System, Threat Detection System	Upload evidence of the process for implementing and managing enterprise logging, log aggregation, and threat detection systems. Examples: Logging Policy or Procedure: A documented policy that defines how long audit logs are retained, minimum storage capacity requirements, and procedures for archival, rotation, and secure disposal. Storage Utilization Logs: Logs or exports showing current and historical log storage usage across systems or centralized log platforms. Audit Records or Review Logs: Evidence that storage usage and retention compliance are regularly reviewed (e.g., tickets, review checklists, audit reports). Detection Rules or Use Case Examples: Screenshots or exports showing configured rules for detecting specific threats (e.g., brute force attempts, lateral movement, abnormal behavior).
DCF-897	8.6	Enterprise DNS Query Logging and Monitoring	Upload evidence of the process for logging and monitoring DNS queries across enterprise systems and service providers. Examples: Policy or Procedure: A documented policy or procedure that defines which DNS queries are logged, how logs are collected (e.g., from internal resolvers, cloud services, firewalls), and where logs are stored. System Configuration Files: DNS server/firewall settings showing query logging is enabled. SIEM or Log Aggregation Reports: Screenshots or exports showing DNS logs in tools like Splunk or Sentinel. Should include sample queries with metadata (e.g., timestamp, source IP, domain queried). Log Samples: Real or redacted logs showing DNS queries with timestamps, source IPs, and domains. Log Review Records: Proof that DNS logs are regularly reviewed (e.g., tickets, alerts, review logs).
DCF-898	8.7	Collection and Retention of URL Request Audit Logs	Upload evidence of the process for collecting and retaining URL request audit logs. Examples: URL Logging and Retention Policy or Procedure: A documented policy describing how URL requests (e.g., web access logs, proxy logs, DNS queries) are captured, stored, and retained, including timeframes. Proxy/Gateway Configurations: Screenshots or exported settings from systems showing that URL logging is enabled and retention settings are configured. SIEM or Log Aggregation Reports: Evidence that URL logs are collected and sent to a central logging platform (e.g., Splunk, Sentinel), including example entries showing URLs accessed, users, and timestamps. Retention Logs: Reports confirming that URL logs are retained according to policy (e.g., 90 days, 1 year), including storage location and access control measures. Review Records: Alerts or tickets showing logs are monitored
DCF-899	8.8	Collect Command-Line Audit Logs	Upload evidence of the process for collecting command-line audit logs from systems and service providers. Examples: Audit Logging Policy or Procedure: A documented policy that defines which command-line activity is logged (e.g., shell commands, PowerShell, terminal usage), how logs are collected, and where they are stored. System Configuration Files or Scripts: Configuration files (e.g., auditd.conf, Windows Audit Policy settings, or bash history settings) showing command-line logging is enabled. SIEM or Log Aggregation Reports: Screenshots or exports from a SIEM (e.g., Splunk, Sentinel) confirming collection of command-line logs from endpoints or servers, including examples of logged command entries. Log Samples: Real command entries with user, timestamp, and command details. Log Review Records: Documentation showing that command-line logs are reviewed regularly (e.g., security tickets, alert configurations, or audit reports).
DCF-900	8.12	Service Provider Log Collection and Monitoring	Upload evidence of the process for collecting and monitoring logs from service providers. Examples: Log Collection and Monitoring Policy or Procedure: A documented policy outlining requirements for collecting, storing, and monitoring logs from third-party service providers, including what log types are required (e.g., access logs, API calls, authentication events). Contracts/SLAs: Contracts or agreements that specify log retention, availability, and access requirements for security monitoring purposes. SIEM Reports or Screenshots: Evidence that service provider logs are ingested into a central SIEM or log aggregation tool (e.g., Splunk, Microsoft Sentinel), including log source IDs and sample log entries. Log Review Records :Documentation of regular log reviews (e.g., meeting notes, ticket records, or automated alerts) showing ongoing monitoring of service provider activity. Alert Dashboards: Screenshots of alerts or dashboards monitoring provider activity.
DCF-901	9.4	Unauthorized Browser and Email Client Extension Restrictions	Upload evidence of the process for restricting unauthorized browser and email client Extension Examples: Policy/Procedure: a documented policy or SOP describing how browser and email client extensions are reviewed, approved, and restricted within the organization. Group Policy or MDM Configuration Reports: Screenshots or exports from tools like Microsoft Intune, Jamf, or Google Admin Console showing enforced extension allow/block lists. Approved List: Inventory of approved permitted extensions. Security Tool Reports: Reports from endpoint or browser management tools showing extension inventory, usage and enforcement of restrictions. Audit Logs: Logs showing detection or blocking of unauthorized extensions, with actions taken (e.g., alerts, removal, user notifications).
DCF-902	10.5	Anti-Exploitation Features Enabled	Upload evidence of the process for enabling anti-exploitation features on systems and applications. Examples: Policy/Procedure: A documented policy or procedure that outlines how anti-exploitation features are configured and enforced across systems. System Configuration Reports: Exported settings or screenshots from system management tools showing that anti-exploitation features are enabled and enforced. Security Tool Console Output: Evidence from endpoint protection platforms (e.g., Microsoft Defender for Endpoint, CrowdStrike, SentinelOne) showing anti-exploitation modules are active and reporting. Audit Logs or Scan Results: Vulnerability scan results or compliance reports verifying that anti-exploitation protections are applied consistently across the environment.
DCF-903	10.16	Centrally Manage Anti-Malware Software	Upload evidence of the process for centrally managing anti-malware software across the organization. Examples: Anti-Malware Management Policy or SOP: A documented policy or standard operating procedure describing how anti-malware is deployed, updated, monitored, and centrally managed across all systems and endpoints. Console Reports/Screenshots: Evidence from anti-malware platforms (e.g., Microsoft Defender ATP, CrowdStrike) showing a centralized dashboard with visibility into endpoint status, threat detections, and policy enforcement. Deployment Logs: Reports showing where anti-malware is installed and active, including device lists, protection status. Update Logs: Logs or records confirming regular updates and active monitoring through the central console, including auto-remediation actions or alerts. Access Records: Documentation showing who has access to manage and monitor the anti-malware platform, supporting the principle of least privilege.
DCF-904	13.11	Tune Security Event Alerting Thresholds	Upload evidence of the process for tuning security event alerting thresholds monthly, or more frequently. Examples: Alert Threshold Tuning Procedure: A documented process or SOP outlining how and when alert thresholds (e.g., in SIEM, EDR, or log management tools) are reviewed and adjusted, including assigned roles and criteria for changes. Change Logs: System logs, configuration management tickets, or change control records showing that alert thresholds were reviewed or adjusted on a monthly (or more frequent) basis. Meeting Notes or Review Reports: Internal security team meeting minutes, reports, or emails confirming the review and tuning of alert thresholds during regularly scheduled intervals. Tool Config Reports: Screenshots or export logs from tools like Splunk, Sentinel, or CrowdStrike showing alert rules and recent modifications with timestamps. Approval Forms: Signed documentation or workflow approvals confirming that alert threshold updates have been reviewed and approved by responsible personnel (e.g., SOC manager or security lead).
DCF-905	15.3	Classify Service Providers	Upload evidence of the process for classifying service providers based on risk and other relevant criteria Examples: Service Provider Classification Register: A documented inventory detailing provider classifications based on data sensitivity, volume, availability, regulatory impact, and risk levels. Classification Methodology Document: A formal policy or procedure describing the criteria and process used to assign classification tiers. Annual Review Records: Evidence confirming that classifications are reviewed at least annually, including meeting notes, logs, or update summaries. process and any resulting changes. Trigger-Based Review Documentation: Records or policy excerpts showing reclassification of service providers due to significant events (e.g., new regulations, service changes, or incidents), including review justifications and approvals. Approval or Sign-Off Forms: Signed records or acknowledgments from responsible personnel (e.g., IT risk, compliance officers) confirming the review and classification of service providers.