This article brings together common customer questions and practical answers based on typical Secureframe workflows, compliance situations and unique tech stacks.

It is meant as quick reference material for day-to-day use of the product.

Breach and notification

Do you have a process for notifying us in case of a data breach?

• Yes, Secureframe will notify customers within 24 hours after confirming a data breach, with up to 72 hours if necessary, depending on the complexity of the breach.

What is your standard window for notification on security incidents or breaches impacting customer accounts or data?

• Less than 24 hours.

Who are other relevant parties for notifications in the incident response plan?

• Other relevant parties for notifications may include customers, financial institutions (acquirers and issuers), and business partners.

Incident response and events

A customer disabled our Google integration after the Vercel security incident. How should we respond?

• No. Secureframe only uses the tokens.list call within the admin.directory.user.security scope, which reads the names of third-party OAuth apps connected to each user's Google account. No Gmail, Drive, Calendar, or any other user content is accessed.

Are Incident Response Tabletop Exercises required for both Type 1 and Type 2?

• Yes, Incident Response Tabletop Exercises are required for both Type 1 and Type 2 audits. Similar to Disaster Recovery exercises, if an exercise done for Type 1 is during the Type 2 audit window, it can be used for both assessments.

Do discussion notes need to be included in the evidence upload for the Security incident response tabletop exercises?

• Ideally yes.

Does Secureframe offer Incident Response Training in the Training Catalog?

• No, Secureframe does not currently have Incident Response Training in the Training Catalog.

  For most frameworks, performing an annual Incident Response tabletop exercise is considered sufficient.

  Clients needing recurring training for contractors (e.g., for PCI-DSS) should develop their own program based on what those contractors are handling and their risk impact.

Has your company experienced a security incident in the past 3 years?

• If no incidents, perform a tabletop exercise. If incidents were tracked and managed according to requirements, no need for tabletop.

How are the two items in IR-02 different? "Incident tracking and resolution" vs. "Address critical security incidents"?

• One involves identifying and documenting incidents (evidence could be a ticket and/or listing of incidents), while the other involves taking corrective actions after the incident (evidence can be in tickets or documented lessons learned in the IR process).

How do I deal with Security Incident Response tests?

• If you’ve had recent security incidents, no tabletop exercise is needed. If not, you must do the tabletop. If you’ve tracked and managed security incidents according to requirements (logging, tracking, and remediation), no tabletop exercise is required.

How to pass Address critical security incidents if you have never had an incident?

• Customers can disable the test and note that no incidents have occurred or upload a screenshot from their threat detection dashboard to prove no incidents have happened.

Is a tabletop exercise sufficient for documenting key learnings from a security incident?

• Yes, as long as process improvements are identified from the tabletop exercise.

What happens if we haven’t had a security incident?

• Customers can prove the negative by showing a screenshot of their threat detection tool showing no incidents. Alternatively, you can mark the test as non-occurrence, disable it, and note it in the justification. Having a procedure for handling incidents is still good practice.

What is the purpose of having documented incident response procedures for when stored PAN is found where it is not expected?

• Having documented incident response procedures that are followed in the event that stored PAN is found anywhere it is not expected to be, helps to identify the necessary remediation actions and prevent future leaks.

What processes or mechanisms should be implemented for reporting and addressing security incidents and vulnerabilities?

• Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including customers being able to securely report security incidents and vulnerabilities to the provider, and the provider addressing and remediating suspected or confirmed security incidents and vulnerabilities according to Requirement 6.3.1.

What should incident response procedures include upon the detection of stored PAN anywhere it is not expected?

• Incident response procedures should include determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable; identifying whether sensitive authentication data is stored with PAN; determining where the account data came from and how it ended up where it was not expected; and remediating data leaks or process gaps that resulted in the account data being where it was not expected.

What types of activity should the incident response team or individuals respond to?

• Examples of types of activity the team or individuals should respond to include any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and reports of unauthorized critical system or content file changes.

Incident response plans

Can I store incident response contacts in Secureframe outside of the Incident Response Plan?

• Currently, Secureframe does not have a dedicated feature for managing or storing incident response contacts outside of the Incident Response Plan itself.

  However, here are a couple of potential workarounds:

  Company Settings > Information Security Team:
  You can list key personnel here, especially if those contacts are part of your broader security org. This isn’t intended specifically for incident response, but it may help centralize ownership visibility.

  Create a custom group:
  If you want to define a group of users as your Incident Response Team, you can create a group in Secureframe and assign users to it for easy reference.

  If you're looking for a more structured solution, we’d love to hear your use case — our team is always exploring ways to improve incident response workflows.

How often should the security incident response plan be tested and reviewed?

• t least once every 12 months, the security incident response plan should be reviewed and the content updated as needed, and tested, including all elements listed in Requirement 12.10.1.

How should the security incident response plan be modified and evolved?

• The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.

re requirements related to an incident response plan applicable to all entities?

• Yes, requirements related to an incident response plan are applicable to all entities, to ensure that there are procedures to follow in the event of a suspected or actual breach of the confidentiality of cardholder data.

What can proper testing of the security incident response plan identify?

• Proper testing of the security incident response plan can identify broken business processes and ensure key steps are not missed, which could result in increased exposure during an incident.

What can the test of the incident response plan include?

• The test of the incident response plan can include simulated incidents and the corresponding responses in the form of a “table-top exercise” that includes participation by relevant personnel.

What elements should an incident response plan include?

• n incident response plan should include roles, responsibilities, and communication and contact strategies; incident response procedures with specific containment and mitigation activities; business recovery and continuity procedures; data backup processes; analysis of legal requirements for reporting compromises; coverage and responses of all critical system components; and reference or inclusion of incident response procedures from the payment brands.

What is important to keep up to date in the incident response plan?

• It is important to keep the plan up to date with current contact information of all individuals designated as having a role in incident response.

What is the purpose of having a comprehensive incident response plan?

• Without a comprehensive incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as risk of financial and/or reputational loss and legal liabilities.

What is the purpose of including monitoring and responding to alerts from security monitoring systems in the incident response plan?

• Responding to alerts generated by security monitoring systems that are explicitly designed to focus on potential risk to data is critical to prevent a breach and therefore, this must be included in the incident-response processes.

What should the incident response plan be thorough and contain?

• The incident response plan should be thorough and contain all the key elements for stakeholders (for example, legal, communications) to allow the entity to respond effectively in the event of a breach that could impact account data.

What types of security monitoring systems should be included in the incident response plan?

• The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to Intrusion-detection and intrusion-prevention systems, network security controls, change-detection mechanisms for critical files, the change-and tamper-detection mechanism for payment pages, and detection of unauthorized wireless access points.

Additional customer questions

How often should logs be checked to minimize the amount of time and exposure of a potential breach?

• Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach.