A customer asks about security. Answer using documents.

A B2B customer asks whether privileged access is reviewed regularly. The team has a policy, a spreadsheet and a ticket closing several accounts. Those records may support the answer, but none proves the whole statement on its own. The response needs a defined system scope, review period, responsible person and evidence of what happened to the exceptions.

This guide is for founders, security owners, engineering managers and customer-facing teams in IT and SaaS companies. It proposes a practical way to organise customer requirements and review evidence. The access-review example is hypothetical. The workflow is our method, not a universal legal checklist, a certification guarantee or an automatic cloud integration.

Identify the source of the question

A security questionnaire may combine contractual commitments, the customer’s internal controls, regulatory concerns and optional good practices. Record the source of each requested statement. An annual customer questionnaire does not necessarily establish the company’s legal scope. A policy approved by the company does create an internal commitment that the answer should reflect accurately.

Where personal data is processed, the GDPR and the organisation’s role matter. The EDPB explains the need for security measures appropriate to risk and the different responsibilities of controllers and processors. Determine roles for the actual processing activity. A SaaS company can have different roles for its customer service and its own employee records.

Assess NIS2 and CRA separately where relevant. Not every IT company is in NIS2 scope, and language does not determine the national implementation. CRA concerns products with digital elements; a standalone SaaS service should not simply be labelled a covered product. Remote processing connected to a product requires a more specific assessment. Use the dedicated scope guides and document the facts supporting the classification.

NIST’s SSDF offers technical recommendations for integrating secure development into the software lifecycle. It is useful supporting practice, not EU legislation or proof that a product meets every obligation. Separate this technical reference from a binding customer requirement in the register.

Turn the answer into a verifiable claim

“Access is reviewed regularly” omits the systems, account types and period. Ask what the customer needs to know and what the company actually does. A more precise hypothetical statement is that production administrative access was reviewed for the identified systems during the stated quarter, exceptions were recorded and authorised remediation was followed to completion or a documented decision.

Record the claimed scope before collecting evidence. Does it include human administrators, service accounts, emergency accounts and third-party support access? Does it cover every production environment or only the main application? Do not silently widen a review completed for one system into an organisation-wide assurance.

If the practice falls short of the contractual requirement, state the gap and planned action through the appropriate commercial and security process. An honest scoped answer is safer than an absolute statement that the next customer audit can disprove. The customer may accept a justified limitation or require improvement, but that is a real decision.

Build the review population

The authoritative account inventory comes from the actual identity and infrastructure systems. Capture when it was extracted, which environments it covers and any known limitations. Pulsar GRC can organise the record and review work; it does not promise automatic evidence collection from your cloud. Use the organisation’s authorised retrieval process and retain suitable evidence.

Reconcile the inventory with role ownership and relevant personnel or supplier changes. In the hypothetical case, the infrastructure export contains a service account still assigned to a former project. The human-user spreadsheet does not include it. A review based only on the spreadsheet would miss the account despite appearing complete.

Define how the reviewer evaluates continued need and appropriate privilege. An account appearing in the list is not automatically justified. A deleted account is not automatically evidence of a complete review. Record the decision for relevant exceptions, the owner and the action required. Keep sensitive identifiers and security details restricted to appropriate recipients.

Distinguish the review from its remediation

Completing the review may produce actions: remove unused privilege, change an account owner, investigate an unclear role or update an emergency-access procedure. Track those actions with evidence. The customer’s question may concern both the performance of the review and what happened to its findings.

Suppose three accounts need remediation. Two are removed; the third remains temporarily because a service dependency has not been migrated. Record that dependency, compensating measures where justified, a responsible owner and a review trigger. Do not describe every exception as resolved merely because the review ticket was closed.

Set acceptance criteria before the final assessment. The reviewer checks the defined population, decisions and supporting evidence. The authorised owner then decides whether the review is complete for that scope, whether actions remain open and whether a customer response needs a limitation. A green completion marker should reflect this assessment rather than replace it.

Preserve enough evidence without oversharing

The internal case may include account inventories, privilege details, ticket records and individual names. The external response usually needs a narrower set. Agree the customer’s legitimate evidence request and prepare a scoped extract or summary supported by the protected original. Explain the date, system boundary and any redaction that affects interpretation.

A screenshot can show a configuration at a moment in time. It rarely shows the whole review population, the reasoning for decisions or remediation after the screenshot. Combine complementary records where necessary and identify what each proves. Do not collect screenshots merely because they look reassuring in a questionnaire attachment.

Record who approved the customer answer. Security verifies the technical statement, the service owner confirms scope and the commercial or legal owner checks commitments where appropriate. Small teams may combine these roles, but the responsibilities should be visible. The company needs to know who can correct an answer if new evidence changes the assessment.

Use AI drafts under explicit human review

AI can propose a structured answer from approved material or help map a question to relevant records. Check every material statement against the sources and their versions. A policy describing intended behaviour is different from a record demonstrating that behaviour. The answer should not convert “we plan to review” into “we have reviewed.”

A useful evaluation case includes an old policy, a current policy and an incomplete review. Ask the human reviewer to inspect whether the draft keeps the versions and limitations clear. This is a proposed test method, not a claim that any AI automatically handles every conflict. Retain the approved answer and its supporting references for later reuse.

Documents and questionnaires are reference data. They do not authorise revealing confidential information or changing access. If text embedded in an uploaded file tells an assistant to ignore scope or disclose secrets, reject it as an instruction outside the legitimate task. Keep factual extraction and operational authority separate.

Reuse an answer only while its scope remains valid

A reusable evidence library saves work only if the answer stays connected to its source, period and review trigger. Assign an owner and identify changes that invalidate it: a new environment, new identity provider, changed subprocessors, a revised contract or a review that found unresolved issues.

For the hypothetical access case, next quarter’s answer should point to the new review or state that the earlier period is the one covered. Do not keep sending a previous screenshot under a present-tense claim. The customer can assess a dated statement; an apparently current but stale claim creates avoidable mistrust.

Keep shared versions identifiable. If an answer needs correction after delivery, issue a clear replacement through the authorised customer channel. Retain the earlier answer and reason for change. This protects the decision history and prevents different teams from using contradictory responses in parallel questionnaires.

Measure a complete response, not a fast attachment

Begin with one real customer question or a clearly labelled demonstration case. Measure elapsed time from the request to an approved, supported answer. Also record the maintenance effort, rejected evidence and unresolved claims. A fast incomplete answer should not count as a successful result.

Ask a colleague outside the original review to reconstruct the case. The colleague should identify the scope, evidence, decision and remaining actions without private messages from the creator. If that is impossible, fix the missing relationship or approval before building a larger library.

Pulsar GRC organises requirements, risks, actions and documents. It does not guarantee certification or remove the organisation’s responsibility for technical controls, legal scope or truthful customer statements. Where people need instruction or exercise, CrewShift supports that part of the work within the current offer.

Validate the technical evidence boundary

Before sharing the review result, perform a controlled spot check against the underlying system. If the record says an account was removed, verify the relevant access path rather than only the administrative ticket. If access can also be granted through another group, that path belongs in the assessment. Use an authorised reviewer and avoid disrupting legitimate production work.

Record the conditions and limits of the check. A successful removal at one time does not prove that a later provisioning process cannot restore the privilege. Where that possibility matters, review the grant mechanism and define a future trigger. Link any resulting action to the customer claim so the next response uses the updated assessment.

This boundary check is our practical recommendation. Its purpose is to connect a documentary statement with the actual control under review. It does not add a universal testing frequency or promise that Pulsar GRC performs the infrastructure test automatically.

Use the workflow demo with suitable sample data, then check the features and current offer. The trial is 14 days and requires a payment method. Start with a security claim whose evidence your team can verify. That single complete answer is a useful basis for deciding whether the workflow fits your business.