Cybersecurity CRM
In cyber security the work sold is tied to a date window and a written authorisation; when the scope and the authorisation document do not match, the test does not start. The report delivered is sensitive too — as much as who may see it, when the findings will be retested has to be tracked.
The date the written authorisation was received is a field on the project record; while that field is empty, the rule defined at setup stops the record moving to the testing stage.
- Keep the test scope, the environment and the test window dates in fields on the project record, and set a rule so the stage does not move on before the written authorisation arrives
- Track report delivery and the retest date as fields, drop the ones whose deadline is approaching into a list and open a task for the person responsible
- Limit access to the report and its attachments with role-based authorisation, and determine from the role definition which user can see the record
- Keep monitoring and subscription renewal dates under the account, and queue the request opened on an incident notification and route it with the assignment rule defined at setup
| Test Project | A test is a project record; the number of assets in scope, the environment and the start and end dates of the test window sit in its fields. |
|---|---|
| Written Authorisation | The client's written authorisation is a date field; while the field is empty, the record moving to the testing stage is blocked by the rule defined at setup. |
| Retest Date | Report delivery and the retest are each date fields; files whose deadline is approaching drop into a list and a task is opened for the person responsible. |
| Report Access | The record and its attachments are subject to role-based authorisation; which user sees the report is read from the role definition. |
A penetration testing job is defined not by the quote but by the scope: how many addresses, how many applications, which environment and which date range. After the quote, that information stays in an email chain, and on the morning the test is due to start somebody goes looking for whether the client's written authorisation has arrived. Once the report is delivered the job closes there; yet the period given for the retest that would confirm the findings have been closed expires a few months later, and nobody sends a reminder. The report itself is a separate problem: a document that names open vulnerabilities should not sit in a folder everyone in the company can reach.
In Rapitek CRM every test is a project record; the number of assets in scope, the environment, the start and end dates of the test window and the date the written authorisation was received are fields on that record — and while the authorisation field is empty, the rule defined at setup stops the record moving to the testing stage. Because report delivery and the retest date are fields, the ones whose deadline is approaching drop into a list and a task is opened for the person responsible. The record and its attachments are subject to role-based authorisation; which user sees the report is determined by the role definition. The renewal date of monitoring and subscription services sits under the same account; when an incident notification comes in, the request that is opened drops into the queue and goes to the team on duty through the assignment rule defined at setup.
The scope of the plans and the separately priced items are set out on the pricing page.
