Skip to main content

Penetration test scheduling and FAQs

How to schedule your organization's Strike Graph pen test and answers to FAQs

Elliott Harnagel avatar
Written by Elliott Harnagel
Updated over a year ago

If you’ve already completed a penetration test (pen test) with Strike Graph, and you'd like to learn about pertinent next steps, check out our Penetration test results article.

If you’ve purchased a pen test as part of your Strike Graph contract, contact your Customer Success Manager (CSM) to get the scheduling process started. In order to get your test on the calendar, the Penetration Test Scope (Statement) of Work (SoW) document must be completed and signed. Once you have signed the SoW, our pen test team will send you the Penetration Test Rules of Engagement (RoE) document, which confirms the dates and times of the test and the scope of the testing. Once the RoE document has been approved and signed, your test will officially be scheduled.

Usually, our penetration test team has availability about two months out. You'll want to fill out the Scope of Work and the Rules of Engagement as soon as you have identified the need for a penetration test in order to reserve your spot on the calendar.

We schedule penetration tests in three-week blocks, or sprints. At the end of the three weeks of testing, a member of the penetration test team will send you your completed penetration test report. The report will include details on the vulnerabilities identified, the risk ranking of each vulnerability (high, medium, or low), and some information on remediation steps for the vulnerabilities.

After reading your report, if you have additional questions for our testing team, you can email them directly, or let your CSM know. If you'd like, we can schedule a meeting with the testing team to go over any questions in detail.

For more general information on penetration testing, check out our Pen Test FAQ and Interview with a Penetration Tester blog posts.

SOC 2 vs. ISO 27001 Penetration Testing

Strike Graph offers two types of penetration tests: one that is more suitable for companies pursuing a SOC 2 audit, and one that is more suitable for companies pursuing an ISO 27001 certification. A detailed breakdown of the differences between the two tests can be found here.

The main difference between the two is that the scope of an ISO 27001 penetration test is not as limited as a SOC 2 test, and companies have the option of allowing our testers to exploit vulnerabilities during an ISO 27001 test to get more "real-world" information on what actual attack would look like. Our testers will never exploit vulnerabilities during a SOC 2 penetration test.

Penetration Test Scope of Work (SoW) Questions

Your CSM will send this document via PandaDoc, our e-signature platform. Guidance for responding to SoW questions is outlined below:

Question #1: What specific hosts, network address ranges, or applications should be tested:

  • This is where you define the scope of what you want our team to test. With a standard pen test, you can include a maximum of two websites and one API, as well as the relevant servers that support the websites and API. We usually recommend that you test against your production environment since that is what an attacker would be up against. We can test against a staging environment, but we ask that we only test against staging if it is identical to your production environment in terms of web applications and infrastructure (so that the test is still an accurate representation of your product’s security). See Question #5 for more details.

Question #2: What specific hosts, network address ranges, or applications should explicitly NOT be tested:

  • Here you can define hosts that you do not want our team to test. Our team will only test what you have defined in the previous question, but if you have any particularly sensitive services that you really don’t want to be touched, list them here.

Question #3: Identify all third parties (cloud providers, invoicing, etc.) used with the platform in the scope of the pen test. Please notify these providers of the date(s)/time(s) of the pen test ahead of our start date.

  • It is good practice (and often a contractual requirement) to notify your vendors that the test is going to be performed. Note: The major cloud providers (AWS, Azure and GCP) all have clauses in their standard terms of service that allow for penetration testing of infrastructure hosted using their services. Therefore, if the scope you have defined in Question 2 only includes AWS/Azure/GCP resources, there is no need to notify or obtain specific permission from these providers.

Question #4: Confirm whether the scope of the Pen Test includes a Production or Testing/Stage environment.

  • Our team identifies vulnerabilities, but does not exploit them. So, the risk of damaging anything in production is very small. For that reason, we generally recommend testing against the production environment as that gives the most effective “real world” results against the environment where you are trying to protect sensitive information. At the end of the day, though, it is your decision on which environment we test.

Question #5a: Please provide at least one set of credentials for the application(s):

  • One of the tests that our team performs is testing the ability of a user on your platform to escalate their privileges, or otherwise cause issues once they have already logged in. In order to perform these tests, our team needs a test or dummy account set up that they can use for testing purposes. Please include credentials (username/password) for the account here. The pen test team will also email you a couple days before your test is set to begin to request the credentials, if you’d prefer to create the account closer to when testing kicks off.

Question #5b: If remote connection is needed provide the procedure here

  • If a remote connection is needed to use the above credentials to log into your application, please outline the steps here. Once again, if you are going to provision the testing account at a later date, you can include this info when our testing team emails you the week prior to the test.

Penetration Test Rules of Engagement (RoE) Questions

There is only one question that requires your answer on the Rules of Engagement document:

Question #1: Provide contact information for a primary and secondary point person in the event of any unexpected blocks during the Pen Test period.

  • Please give us a couple people from your team that our pen testers can contact if they run into issues or roadblocks during the testing process.

Everything else on this document is information that our team is sharing and does not require a response other than your signature at the end. It is important that you read the document carefully before signing so that you understand the information being shared. The RoE document outlines:

  • The dates and times of the testing period.

  • The IP addresses of our team's attacking systems (so that you can identify any alerts generated by our team during the testing phase).

  • Our policy on how the pen test team stores information captured from your systems.

  • Information on what activities may force our team to cancel the test and re-schedule. Usually, the only stipulation is that if our team is blocked by an issue during the testing period and neither point person designated has responded within 48 hours, we may cancel your test.

Next Steps

Once your pen test has been completed, the pen test team will email you the report. Once you receive your report, if vulnerabilities have been identified, you should begin documenting remediation steps. For more details on this process, see our Penetration test results article.

Note: It's normal to have one or more vulnerabilities identified as part of the penetration process. It is not necessary to obtain a "clean" pen test report for the purposes of a SOC 2 audit. The auditors will want to see that a penetration test was completed and that remediation steps are underway, where necessary. As long as remediation is documented, the number of vulnerabilities identified will not be of issue to the auditors.

Did this answer your question?