How do we log customer questionnaires so none are late or answered inconsistently?

Start

A customer's security request reaches someone in the organisation

It may be a questionnaire in a portal, an email to a manager, a question on a sales call, a due diligence call, an audit request or a security schedule in a draft contract. Each of these is a request, and each is a statement your organisation will be held to once answered. Late and inconsistent responses start when a request is handled where nobody else can see it.

• Then: Does it report or ask about a security incident?

Decision

Does it report or ask about a security incident?

A message that tells you of an incident, or asks whether one has happened, is not a questionnaire. The tracker does not hold it. It goes to the incident route, which decides what it is and whether anything must be reported. Judgement: if you cannot tell, treat it as an incident message first and log the questionnaire part afterwards.

• Yes, or not known: Send it to the incident route, not the log
• No: Log it the same day with one response lead

Outcome

Send it to the incident route, not the log

Your incident response procedure owns what happens next, including any duty to tell a customer or a regulator. The questionnaire process answers none of that. Judgement: do not reply to the customer about the incident from the questionnaire process.

Step

Log it the same day with one response lead

Whoever receives it logs it, the day it reaches anyone. Enter an ID in the form R-yyyy-nnn, the customer by reference, the kind of request, the date it reached the organisation, the date the customer gave, the response lead and where the original is kept. Keep the original in the tracker's store, not a shared mailbox. A salesperson who receives it passes it on and answers nothing about security.

• Then: Is the sender a customer or a prospect in a live opportunity?

Decision

Is the sender a customer or a prospect in a live opportunity?

Triage starts here, within the window the pack sets (2 working days by default). A sender who is neither a customer nor a prospect in a live sales opportunity is declined, and the reason is recorded. Sales may still send the public overview and public evidence. Judgement: if you cannot tell, ask the account owner before declining.

• No: Reply politely, send nothing, record the reason
• Yes: Count questions with a current, a stale and no library answer

Outcome

Reply politely, send nothing, record the reason

Set the status to Declined and write the reason in the note, so the log shows the request was seen and decided. A declined request needs no due date and holds no questions in the monthly count. Send the public overview and public evidence only if sales would send them to anyone.

Step

Count questions with a current, a stale and no library answer

Enter the total and the three counts, which must add up. A current answer needs only release, a stale one needs its topic owner to confirm it, and a question with no answer needs a topic owner to write it and the Head of Information Security to approve it. Write reuse as a count, for example 198 of 300, never as a share. Check the tracker too: a response to the same customer or standard form inside the reuse window (12 months by default) may be reused where its answers are still current.

• Then: Can the date be met with all answers confirmed or written?

Decision

Can the date be met with all answers confirmed or written?

Compare the working days left with the work the counts show. The pack's default is that fewer than 5 working days, with answers still to confirm or write, means agreeing a later date before work starts. A date that has already passed is the same problem, and the customer is told today. If you do not know how long the topic owners need, answer no.

• No, or not known: Agree a new date with the customer before the old one
• Yes: Draft from the library, never from the last form

Step

Agree a new date with the customer before the old one

The account owner agrees the new date with the customer. Change the due date in the log and write the reason in the note, so the request is then due on the new date and the change is visible when you report. Never let a request lapse without a conversation. The pack expects no request to be left past its date without a record.

• Then: Draft from the library, never from the last form

Step

Draft from the library, never from the last form

Use a current library answer unchanged. If an answer needs to change, change it in the library first, with its owner's approval, then use it. Copying the last form is how an old or wrong answer returns. Judgement: update the status to Drafting as work starts, so the log shows who is holding each request.

• Then: Run the over-commitment check and get the approvals

Step

Run the over-commitment check and get the approvals

Check every answer for claims the evidence does not support, a scope wider than the evidence, and any date, action, absolute word, right of audit or access, or liability. Approvals follow the pack's rules by kind of answer. Nobody approves an answer they wrote. Record who cleared each flag.

• Then: Does the response or covering email promise to do something?

Decision

Does the response or covering email promise to do something?

A commitment is a promise to do or provide something, with a date or a continuing duty. It may sit in an answer, a covering email or a call. Examples are sending a refreshed overview in November or a test report once an agreement is signed. If you are not sure, treat it as a promise.

• Yes, or not known: Is the promise backed by a clause, a control or an approved plan?
• No: Send it, then record the date and keep an exact copy

Decision

Is the promise backed by a clause, a control or an approved plan?

The log records what supports each commitment: a contract clause, a control in place or an approved plan. A commitment with none is not sent. Take it out of the response, or send it to Legal. If you do not know what backs it, answer no.

• No, or not known: Do not send it: remove the promise or take it to Legal
• Yes: Get Legal's decision, then log the commitment

Outcome

Do not send it: remove the promise or take it to Legal

An unsupported promise is the kind that later turns into a correction. Remove it from the response. If the customer needs it, Legal decides the wording and whether the contract is the right place. The response goes only when the check is clear.

Step

Get Legal's decision, then log the commitment

A promise found in an answer goes to Legal before the response is sent, and Legal and the Head of Information Security approve a contractual commitment. Then use the Commitments sheet. Write the promise in the words the customer received, name an owner by role, give a due date or the word Continuing, and enter what supports it. Put its CM ID on the request. The pack's default for a commitment due soon is within 14 days; change it to your own practice.

• Then: Send it, then record the date and keep an exact copy

Step

Send it, then record the date and keep an exact copy

Release evidence by its sharing tier and check its expiry on the day. When the response leaves, enter the submitted date and the reference of the exact copy as sent, with its approvals, the evidence versions it cited and its covering statement. The pack's default is to keep this for 3 years after the relationship ends, or longer where a contract or law asks.

• Then: Is any open request or commitment past its date, or unknown?

Decision

Is any open request or commitment past its date, or unknown?

Read the list of open requests past their due date and the open commitments past theirs. The pack requires the report monthly. Judgement: also read the list weekly, because a monthly look finds a late request after the customer has. If a date is missing from a row, count the row as late.

• Yes, or not known: Tell the customer today, agree a new date, report the gap
• No: Has any answer already sent turned out to be wrong, or unknown?

Outcome

Tell the customer today, agree a new date, report the gap

For a request, the account owner tells the customer today and agrees a new date. Record the reason and the new date. For a commitment, the owner either delivers it or agrees a new date with the customer; judgement, and your procedure may name who confirms it. Report each gap by name, for example 1 open request is past its due date, never as a score.

Decision

Has any answer already sent turned out to be wrong, or unknown?

A wrong answer is found by the owner at a review, by a customer, or by someone comparing two responses. The tracker holds no answers, so the search runs over the tracker and the stored responses. If you cannot tell whether an answer was used, search before closing the request.

• Yes, or not known: Use the correction route and log the correction
• No: Close the request and report the five monthly counts

Outcome

Use the correction route and log the correction

Withdraw the answer from the library at once, list every response that used it, and rate the correction minor or material. Log the correction in the commitments log as Corrected. The detail of the route is its own question.

Outcome

Close the request and report the five monthly counts

Add new and adapted answers to the library and close the request when nothing is open. Report five counts: responses sent by their due date, questions answered from current library answers, library answers past their review date, evidence items expired or expiring, and commitments past their due date. Each is a count with the gaps named, such as 3 of 4, and the pack combines none into a score.