How to Answer an Enterprise Security Questionnaire for Software You Inherited

Answer an enterprise security questionnaire as a set of scoped, reviewable claims—not as a quiz that rewards the most “yes” answers. For every material question, name the service boundary, current state, evidence, owner, observation date and any disclosure restriction. If the team cannot verify a fact about inherited software, NOT VERIFIED is the internal starting state; convert it through safe evidence gathering before submission, or disclose the gap and its owner honestly.

There is no universal list of eight controls that always decides an enterprise deal, and the remaining questions are not mere paperwork. The buyer's data, integrations, user roles, criticality, sector and risk policy determine what matters. Your job is to make the actual state legible enough for the buyer's security and business owners to decide.

Download the enterprise security questionnaire evidence ledger to keep the response, evidence, approval and review date together without putting credentials, customer data or exploit details into the file.

Start with the review scope, not row one

Before engineering researches two hundred questions, schedule a short scope call or send a written clarification. Confirm:

• the exact product, environment, feature set and deployment model being evaluated;
• what customer and user data will enter the service, including regulated or confidential data;
• whether the product will connect to the buyer's identity, network, data warehouse or internal systems;
• customer and vendor administrator roles, support access and machine-to-machine identities;
• expected availability, recovery and operational criticality;
• countries or regions in which data, support and subprocessors may operate;
• the requested assurance artifacts and whether restricted evidence can be reviewed under controlled access;
• the security-review owner, follow-up process and actual submission date;
• which answers or attachments may become part of the contract or security schedule.

That scope changes the answer. “We support SSO” is incomplete if it applies only to one plan, one identity protocol or workforce users but not administrators. “Data is encrypted at rest” is incomplete if it describes a managed database while file storage, backups, search indexes or support exports sit outside the statement.

Some buyers use a standard format. The Cloud Security Alliance's current CAIQ v4.1 has 283 questions, while its CAIQ-Lite has 138 questions across 17 domains. Shared Assessments provides SIG Core and SIG Lite variants. Others use a custom sheet. The format helps organize work; the row count does not tell you which claims the buyer will accept.

Give every answer a response record

A bare yes/no cell hides the information a reviewer needs. Maintain an internal record behind each material answer:

Use six response states internally:

• VERIFIED — current evidence supports the exact statement for the stated scope.
• PARTIAL — the control exists, but material boundaries or exceptions remain.
• PLANNED — approved work has an owner and target, but the control is not implemented today.
• NOT APPLICABLE — the customer scenario is genuinely outside the control, with a written rationale.
• NOT VERIFIED — evidence is missing, contradictory or not yet reviewed.
• RESTRICTED EVIDENCE — the claim is verified, but the supporting detail needs controlled review rather than an email attachment.

NOT VERIFIED is not the same as “no.” It says the decision lacks evidence. PLANNED is not the same as “yes.” It says a current gap has an authorized next step. NOT APPLICABLE is not a way to avoid research: explain which architectural or business fact makes the question inapplicable.

Match the evidence to the strength of the claim

Security evidence has layers. Do not use a policy to prove operating effectiveness or a cloud-provider brochure to prove your application configuration.

1. Policy and control design — approved policy, standard, procedure, role assignment or architecture decision. This proves what the organization intends and requires.
2. Implementation — configuration export, infrastructure definition, access-control rule, code path, data-flow map or provider setting. This proves what appears to be implemented for a defined scope.
3. Operation — dated access review, restore exercise, incident simulation, alert test, deployment record, vulnerability-remediation trace or sampled log. This proves the control operated under observed conditions.
4. Independent assurance — a scoped SOC report, ISO/IEC certificate, assessment or penetration-test report. This adds independent evidence within its stated system, period, method and limitations.

An independent report is stronger than a self-assertion for the claims it actually covers. It is not a universal guarantee. Read the system boundary, report period, opinion, exceptions, subservice organizations and customer responsibilities before reusing it as evidence for a particular product answer.

Before answering inherited software, establish the baseline

If the current team did not build the product, begin with control and provenance. A repository may not match production. A cloud setting may describe one account but not the live tenant. An old questionnaire may have been correct before a migration, provider change or staff departure.

Map at least:

business owner → source owner → build definition → deployed artifact → running environment → runtime configuration → data stores and flows → operational owners

Then verify:

• company-controlled administrators, recovery methods, billing and support authority;
• the revision or artifact running in each customer-facing environment;
• databases, object storage, queues, search indexes, analytics, backups and manual exports that hold customer data;
• privileged human and machine identities, including former supplier access;
• deployment, rollback, alert and recovery paths;
• current subprocessors and integrations, not just invoices from the original build;
• unresolved incidents, vulnerabilities, unsupported components and customer commitments.

If ownership is still unclear, use the first-72-hours access and ownership guide before making broad security statements. For a cooperative supplier transition, the 30-day takeover checklist establishes source-to-production, recovery and release evidence.

If the security review is part of buying the product rather than selling it to a customer, use the small-SaaS technical due diligence guide. It adds rights, transaction, provider-economics and transition evidence that a supplier questionnaire does not decide.

Ten evidence lanes to prioritize by customer risk

These lanes recur in questionnaires, but their order and acceptance threshold are customer-specific. Start with the lanes connected to the buyer's data and critical operations.

1. Service boundary and data handling

Produce a current data-flow view: entry points, processing, stores, replicas, logs, backups, exports, subprocessors, regions, retention, deletion and support access. Separate customer content, account data, telemetry, billing data and secrets.

For encryption questions, record each covered store or channel, the control owner, key-management boundary and how the configuration was verified. Do not claim “all data” when only the primary database was checked. Do not copy an algorithm name from provider marketing without confirming the actual service and configuration.

2. Identity, authorization and tenant boundaries

Distinguish workforce identity, customer identity, administrator identity, service accounts and support impersonation. Verify MFA enforcement, provisioning, privileged access, periodic review and offboarding for the applicable group.

SSO may be essential for a buyer's workforce workflow, but it is not a universal proxy for authorization. Test whether one customer, role or object can reach another customer's data and whether server-side enforcement agrees with the UI. The AI-built app production audit gives a deeper evidence sequence for object authorization, secrets and privileged access.

3. Logging, detection and customer-visible auditability

Inventory security events and material customer actions. Record what is logged, whether secrets or personal data are redacted, who can alter or delete records, retention, alert ownership and how an investigation ties an event to a product version and actor.

Application logs are not automatically customer audit logs. A buyer may need user-visible history, administrative access records or exportable events with defined retention and integrity. Answer the exact capability rather than treating any logging platform as proof.

4. Backup, recovery and continuity

A green backup job proves creation status, not a usable restore. Record the protected datasets, backup location and access, retention, recovery dependencies, most recent isolated restore, integrity checks, observed recovery result and unresolved gaps.

NIST contingency guidance treats strategy, testing, training and maintenance as connected work. It is written for U.S. federal systems, but the evidence distinction is useful everywhere: state whether RPO/RTO values are contractual targets, design estimates or observed exercise results. Do not convert a provider's infrastructure promise into your application's recovery claim.

5. Incident response and notification commitments

Current NIST incident-response guidance integrates preparation, detection, response and recovery across cybersecurity risk management. A defensible response identifies the incident owner, escalation path, technical containment authority, evidence preservation, communications owner, customer-impact assessment and exercises performed.

Do not invent a universal notification window. Notification duties can depend on the incident, data, contract, sector and law. Any customer-facing time commitment needs the security, operations and qualified legal owners who can actually meet and interpret it.

6. Secure development, release and software supply chain

NIST SSDF 1.1 provides common secure-development language, while CISA's Secure by Demand guide lists buyer-side questions and artifacts such as an SBOM and vulnerability-disclosure process.

Build the evidence set from authorized source and production context:

• repository and branch protections, review/bypass rights and release approvals;
• dependency inventory, lockfiles, runtime images and build/install behavior;
• supported versions and vulnerability-response ownership;
• build artifact and deployment provenance;
• secret handling, environment separation and security testing;
• vulnerability disclosure, triage, remediation and customer communication.

An SBOM is an inventory input. A dependency scanner is a detection input. Neither proves that every runtime component is covered, every finding is exploitable or every customer risk has been resolved.

7. Vulnerability testing and remediation

Separate automated scans, code review, application verification and penetration testing. OWASP's ASVS provides testable application-security requirements; its Web Security Testing Guide combines automated, manual and context-specific techniques.

For each report, record the exact application/environment, dates, assessor, method, authentication level, exclusions, severity model, findings, remediation status and retest evidence. “We ran a scan” is not a penetration-test answer, and “no critical findings” is meaningless without the scope and report date.

8. Subprocessors, external services and AI

Map every third party that receives, stores, processes or can access customer data: hosting, email, support, monitoring, analytics, error tracking, payment, identity and AI/model providers. Record purpose, data classes, region, access, retention/deletion, contract owner, change process and incident dependency.

For AI, distinguish developer tooling from product data flow. The buyer usually needs to know whether its data reaches a model or retrieval provider, which model/provider/version is used, whether inputs or outputs are retained or used for training, how tenants are isolated, which human review exists and how the feature fails or can be disabled.

The FTC has warned AI companies to honor privacy and confidentiality commitments, including commitments about training use. Review current provider terms and the exact product configuration; do not infer the answer from a vendor's homepage.

9. Governance, people and operating records

Policies are not “the easy thirty.” An information-security, access, change, vendor, retention or continuity policy is useful only when its scope matches reality, an owner has approved it, the organization can operate it and exceptions remain visible.

Check staff and contractor onboarding, training, access grants, reviews, offboarding, device expectations, change approval and exception handling. For an inherited product, include the former agency or developer: hidden support access and recovery identities can invalidate a polished policy answer.

10. Independent assurance and customer commitments

Record every assurance artifact with its entity, system scope, date/period, issuer, status, exceptions and permitted distribution. Separately record security commitments in the MSA, DPA, security schedule, SLA, prior questionnaires and sales material.

Do not let engineering approve legal or privacy language alone. Do not let sales turn a target state into a current fact. The submission owner should reconcile questionnaire language with existing and proposed customer promises before the response leaves the company.

Describe SOC 2, ISO/IEC 27001 and NIST accurately

These three labels are often grouped together even though they are different kinds of evidence.

SOC 2

AICPA describes SOC 2 as an examination and report on controls relevant to security, availability, processing integrity, confidentiality or privacy. It is not a certification.

A Type 1 examination generally addresses control design at a point in time. A Type 2 examination adds operating effectiveness over a specified period. Do not promise a standard price, readiness period or observation window: scope, control maturity, evidence, auditor and report period change the work.

If you have a report, answer with the report type, covered system, period/end date, opinion and current exceptions or bridge information as approved. If the report does not cover the product, region or period in the question, say so.

ISO/IEC 27001

ISO/IEC 27001:2022 specifies requirements for an information security management system. An external certification body—not ISO—performs certification. ISO's certification guidance explains how accredited status can be verified.

If certified, provide the exact standard/version, certified entity, certification body, validity/status and statement of scope. A management-system certificate is meaningful evidence inside that boundary; it does not prove every product control or customer-specific promise.

NIST CSF

NIST CSF 2.0 is a taxonomy of cybersecurity outcomes, not a prescribed implementation. NIST's CSF FAQ says NIST does not certify or endorse CSF products, implementations or services.

Use language such as “we map this program to selected CSF 2.0 outcomes for [scope]” only when the mapping exists and is current. Never say “NIST certified.”

Write answers that cannot outrun the evidence

Use patterns with explicit placeholders, then replace each bracket only after its owner verifies it.

Verified pattern: “For [service/environment/data class], [control] is implemented through [system/configuration]. Evidence was reviewed by [owner role] on [date]. [Named boundary or exception] is outside this statement.”

Partial pattern: “The control currently covers [scope]. It does not yet cover [gap]. Until [approved work] is verified, we apply [current limitation or compensating control]. Owner: [role]. Target review: [date].”

Planned pattern: “Not currently implemented. Approved work is [scope], owned by [role], with a target verification date of [date]. This is a plan, not a current control.”

Not-verified pattern: “We have not yet verified [fact] for [scope]. The evidence request is assigned to [role] and we will update this response by [date]. No affirmative security claim is made in the interim.”

Restricted-evidence pattern: “Current evidence exists for [scope and period]. Because it contains sensitive system detail, it is available through [approved restricted-review process], subject to [access condition].”

Do not submit invented examples such as “TLS 1.2+, AES-256, daily backups, RTO four hours” because they sound conventional. Each value needs a system, boundary, owner and observation behind it.

If you do not have SOC 2

Say exactly that. Then ask the buyer which decision it is trying to make and what alternative or compensating evidence its process allows. A useful clarification is:

“We do not currently hold a SOC 2 report for this service. Which risks does your review need independent assurance for, and can your process evaluate scoped evidence or a time-bound exception while those controls are addressed?”

Possible evidence to propose—without claiming it will be accepted—includes a current architecture/data-flow summary, approved policies, access and offboarding records, restore exercise, incident exercise, vulnerability-management record, scoped security assessment, penetration-test summary with remediation/retest status, subprocessor register and an owned remediation plan.

If an examination is genuinely underway, state only facts you can prove: the CPA firm, signed scope, report type, covered system, observation period if applicable and target date approved for customer communication. “SOC 2 in progress” without those facts can be more misleading than a clear “not currently available.”

Share security evidence without creating another risk

NIST's guidance on managing information exchanges says protection should remain commensurate with risk before, during and after exchange. Treat the customer evidence package as sensitive operational material.

• classify each artifact before sharing;
• confirm the recipient and purpose;
• share the minimum necessary version, with customer data and secrets removed;
• use named access, MFA, expiry and download controls where appropriate;
• prefer summaries or controlled review for detailed network, vulnerability and configuration evidence;
• record who approved and accessed the package;
• remove or expire access after the review;
• follow the report issuer's distribution wording and qualified counsel's instructions.

Never send credentials, tokens, private keys, production-data exports, unredacted admin-user lists, raw secrets-scan output or unnecessary exploit steps. An NDA can define obligations; it does not replace access control, minimization or expiry.

Build a reusable answer library without freezing old truth

After submission, preserve the exact approved response and buyer context. Normalize reusable statements by control domain, but retain:

• exact scope and exclusions;
• evidence pointer and observation date;
• control and approval owner;
• report or certificate period/status;
• permitted disclosure class;
• buyer-specific wording that must not be reused;
• expiry or review date;
• change triggers such as new subprocessor, region, model provider, authentication path or incident commitment.

The answer library is not the source of truth for production. It is a reviewed projection of current source evidence. When the product, infrastructure, policy, contract or provider changes, update the evidence first and then the answer.

Use a submission gate

Before sending the questionnaire, require four approvals at the depth the deal needs:

1. Engineering/operations confirms technical scope and evidence.
2. Security/privacy confirms control meaning, risk, data handling and evidence disclosure.
3. Legal/commercial owner reviews contractual, notification, privacy and assurance language.
4. Business owner accepts disclosed gaps, roadmap priority and any commitment proposed to the buyer.

Run a final consistency check across the questionnaire, security overview, DPA, subprocessor list, MSA/security schedule, SLA, trust page and prior customer answers. A polished spreadsheet is not a safe submission if another document makes a broader promise.

If the review exposes structural gaps, separate immediate evidence work from engineering remediation. Recover ownership and close confirmed cross-tenant, secret, access or recovery risks first. Then compare bounded repair with staged modernization using the rewrite, refactor or replatform model. For a stable live product that needs a controlled backlog of enterprise-readiness work, application maintenance can combine remediation, releases and living evidence without pretending to provide certification or legal clearance.

Frequently asked questions

How long does the first security questionnaire take?

There is no responsible universal estimate. Time depends on product and buyer scope, ownership, evidence quality, assurance requests, regulated data, number of environments and unresolved gaps. Estimate the work after the scope call and evidence inventory; keep buyer waiting time separate from engineering effort.

Can AI fill in the questionnaire from our old answers?

It can help classify questions and draft from an approved library, but it should not approve current-state claims. Material answers still need their owner, scope, evidence, date and disclosure review. Do not upload customer-confidential questionnaires or security evidence to an unapproved model provider.

Is a cloud provider's SOC 2 report enough for our SaaS answer?

Usually it proves only the provider controls within that report's boundary and period. Your application configuration, identities, authorization, code, data flows, recovery, support access and customer commitments remain your evidence problem. Review complementary responsibilities and excluded subservices rather than inheriting the provider's conclusion wholesale.

Do we need a penetration test?

Ask what system, threat and assurance decision the buyer needs covered. If testing is required, define scope, environment, authentication, assessor, timing and acceptable report form before commissioning it. Preserve findings, remediation and retest evidence. A vulnerability scan is not automatically a penetration test.

What if an honest gap threatens the deal?

Escalate it early with its exact scope, current risk control, owner and verification plan, then ask the buyer whether its process permits compensating evidence or a time-bound exception. The buyer may still decline. Concealing the gap creates a larger security and contractual problem without proving the deal was ever acceptable.

We do not control every production account yet. Can we submit?

Do not make categorical statements about systems you cannot inspect or control. Mark the affected answers not verified, recover company-controlled ownership, and explain the limitation to the review owner. If the product is live and the former supplier still controls critical infrastructure, start with software project takeover before promising enterprise readiness.

H Product Studio helps teams establish the evidence behind enterprise-readiness claims, close technical gaps in inherited systems and leave a response library the product owner can keep current. We do not issue SOC 2 reports, ISO certificates or legal compliance opinions. Discuss the product and the customer review →