157 common security questions, each with a draft answer written from your own Policyseed policies and the answers you gave the generator, citing the policy section it comes from. Search for the topic of a customer’s question, copy the answer into their portal, form or email, or download the whole library as Excel or Markdown.
Built for the questionnaires that arrive as a web portal, an email thread or a form with no spreadsheet to upload. The answers are built deterministically from your answers, with no AI involved: the same answers always give the same text. Every fact the generator cannot know is left as a [Fill in: …] placeholder. In the sample below, 128 answers come straight from the policies and 29 need your input.
Review every answer before you send it. Customers rely on these statements and often write them into the contract. Send only what is true today: a policy states what you require, not that a control operates.
These answers are for the sample company, Northwind Cloud Inc.Answer the generator questions (in your browser) and come back: every answer then uses your hosting, identity provider, MFA status, device management, tools, owners and data types.
157 answers, 29 need your input. Built in your browser; nothing is uploaded.
157 answers
GOV-01Governance and riskAnswered from policy
Do you have a documented information security program?
Yes. Our written information security program consists of our Information Security Policy and supporting policies covering access control, authentication, change management, incident response, vendor risk, data handling, backups and business continuity. Our Information Security Policy requires every policy to have a named owner, an approver, a version and an effective date, and to be reviewed annually and after any significant change to the business, the technology stack or the threat landscape.
Source: Information Security Policy, sections 4.1 and 4.5 · SOC 2: CC5.3, CC5.1
GOV-02Governance and riskAnswered from policy
Who is accountable for information security in your organization?
Our Security Owner is Dana Whitfield, CTO. Our Information Security Policy gives the Security Owner the authority to set security requirements, halt changes or releases that create unacceptable risk, and escalate directly to Executive Management. Our policies are approved by Priya Natarajan, CEO.
Source: Information Security Policy, sections 4.3 and 5.2 · SOC 2: CC1.3, CC1.2
GOV-03Governance and riskAnswered from policy
How often are your security policies reviewed, and who approves them?
Our Information Security Policy requires our policies to be reviewed annually and after any significant change to the business, the technology stack or the threat landscape. Revisions are approved by Priya Natarajan, CEO, versioned, and communicated to affected personnel within ten business days. The current version took effect on 2026-09-02.
Source: Information Security Policy, sections 4.5 and 5.2 · SOC 2: CC5.3, CC2.2
GOV-04Governance and riskAnswered from policy
Does senior management receive regular reports on security?
Our Information Security Policy requires the Security Owner to give Executive Management a written status report at least quarterly covering open risks, incidents, vulnerability and patch status, access review results, vendor reviews and progress against security objectives, with decisions minuted.
Source: Information Security Policy, section 5.4; Risk Assessment and Management Policy, section 4.11 · SOC 2: CC1.2, CC2.2
GOV-05Governance and riskNeeds input
Do you perform a formal risk assessment, and how often?
Our Risk Assessment and Management Policy requires a formal risk assessment at least annually and after triggers such as a SEV1 or SEV2 incident, a significant change to Northwind or its infrastructure, or the adoption or loss of a critical vendor. Each assessment covers assets and owners, threats, vulnerabilities, existing controls, likelihood and impact, including fraud and misuse of privileged access. [Fill in: the date of your most recent risk assessment]
Source: Risk Assessment and Management Policy, sections 4.1 and 4.2 · SOC 2: CC3.1, CC3.2, CC3.3
GOV-06Governance and riskAnswered from policy
How are identified risks tracked, treated and accepted?
Our Risk Assessment and Management Policy requires a single risk register that records, for each risk, an owner, inherent and residual scores, existing controls, the chosen treatment and actions with due dates. Each risk is mitigated, transferred, avoided or accepted with a recorded rationale. Residual risk is accepted in writing at a level set by its rating, Critical risks only by Executive Management, and every acceptance expires within 12 months.
Source: Risk Assessment and Management Policy, sections 4.3, 4.4 and 4.5 · SOC 2: CC3.2, CC9.1
GOV-07Governance and riskNeeds input
Do you hold a current independent security report or certificate, such as a SOC 2 report or an ISO/IEC 27001 certificate?
[Fill in: whether you hold a current independent assurance report or certificate covering Northwind, its type and its period or issue date, and how customers can request it. If you have none yet, say so, and give a planned date only if an engagement is booked]
No policy covers this: answer from your own records. · SOC 2: CC2.3
GOV-08Governance and riskAnswered from policy
How do you identify the legal, regulatory and contractual requirements that apply to your security program?
Our Information Security Policy requires us to identify the legal, regulatory and contractual requirements that affect information security, including customer contracts, data processing agreements and the laws that apply to us as identified with legal counsel, and to record each in a register of obligations with an owner. The register is updated when a contract with non-standard security terms is signed and is reviewed in full with counsel at least annually.
Source: Information Security Policy, sections 4.15 and 5.9 · SOC 2: CC2.3, CC3.1
GOV-09Governance and riskAnswered from policy
How are exceptions to your security policies handled?
Our Information Security Policy requires every deviation from a policy to go through a documented exception: a written request to the Security Owner stating the requirement affected, the justification, compensating controls, a risk owner and an expiry date no more than twelve months out. Approved exceptions are logged in an exception register and reviewed at each annual review, and undocumented deviations are treated as policy violations.
Source: Information Security Policy, sections 4.13 and 5.6 · SOC 2: CC5.3
GOV-10Governance and riskNeeds input
How many employees and contractors does your company have?
Our headcount is in the 11-50 range. [Fill in: the current number of employees and contractors, and how many of them have access to production systems or customer data]
No policy covers this: answer from your own records. · SOC 2: CC1.3
HR-01Human resourcesAnswered from policy
Do you screen employees and contractors before they start?
Our Human Resources Security Policy requires every candidate for a role with access to Northwind systems, customer data or company finances to be screened before the start date: identity verification, right-to-work confirmation, verification of the most recent employment, and a criminal record check where the law of the candidate's jurisdiction permits it and it is proportionate to the role. Where a check is not permitted, we record the reason and apply an alternative such as additional reference checks.
Do employees and contractors sign confidentiality agreements?
We require every employee and contractor to sign an employment or services agreement with confidentiality and intellectual property terms, and to acknowledge our Information Security Policy and Acceptable Use Policy in writing, before any account, device or system access is issued.
Are personnel required to acknowledge your security policies, and how often?
Our policies require all personnel to acknowledge the Information Security Policy and the Acceptable Use Policy in writing at hire, at each annual policy review and after each material revision. Acknowledgments are kept as evidence.
Source: Information Security Policy, section 4.6; Acceptable Use Policy, section 5.1 · SOC 2: CC1.1, CC2.2
HR-04Human resourcesAnswered from policy
Do you provide security awareness training, and how often?
Our Human Resources Security Policy requires all personnel to complete security awareness training within 30 days of starting and at least every 12 months after that, and phishing recognition is part of the annual training. Personnel who handle personal data also complete data protection training on lawful processing, data subject rights and breach reporting.
Source: Human Resources Security Policy, section 4.4; Acceptable Use Policy, section 5.5 · SOC 2: CC1.4, CC2.2
HR-05Human resourcesAnswered from policy
Do engineers receive secure development training?
Our Secure Software Development Policy requires every engineer to complete secure development training within 30 days of starting and annually after that, covering the OWASP Top 10, our secure coding standards and secret handling. People Operations keeps the completion records.
Source: Secure Software Development Policy, section 4.13; Human Resources Security Policy, section 4.4 · SOC 2: CC1.4
HR-06Human resourcesAnswered from policy
What does your offboarding process cover?
When an engagement ends, our policy requires the Okta account to be disabled and sessions revoked before the end of the last working day, immediately for involuntary departures, and all remaining access removed within one business day. Revocation covers GitHub, GitHub Actions, our accounts on AWS and Vercel, Supabase, Stripe, Datadog and Slack, shared mailboxes, API tokens and any credential the person held. Shared credentials the person could read are rotated within one business day of departure, and when someone changes role, access the new role does not need is removed within five business days.
Source: Human Resources Security Policy, sections 4.6 and 4.8; Access Control Policy, section 4.11 · SOC 2: CC6.2
HR-07Human resourcesAnswered from policy
Are company devices collected and wiped when someone leaves?
Our policy requires company devices to be returned on or before the last working day. Returned devices are locked and wiped through Kandji before reuse, and unreturned devices are wiped remotely within 24 hours of departure.
Do contractors and vendor staff follow the same security requirements as employees?
Our Human Resources Security Policy requires contractors, agency workers and vendor staff with access to our systems to meet the same screening, acknowledgment, training and offboarding requirements as employees. Where the contracting firm performs the screening, we obtain written confirmation that it is equivalent to ours.
Is there a disciplinary process for security policy violations?
Our Human Resources Security Policy requires violations of security policy to be handled through a formal disciplinary process that is proportionate, documented and consistent, with sanctions ranging from retraining to termination of employment or contract and, where the law requires, referral to authorities. Reporting a security incident in good faith, including one the reporter caused, never results in disciplinary action.
Source: Human Resources Security Policy, section 4.11; Information Security Policy, section 4.10 · SOC 2: CC1.5
ACC-01Access controlAnswered from policy
How do you apply least privilege when granting access?
Our Access Control Policy requires access to follow least privilege and need-to-know: each person receives the minimum access their current role requires, as defined in a role-to-access matrix, and nothing is granted for convenience or because a peer has it. Read-only roles are used wherever write access is not needed.
Source: Access Control Policy, sections 4.1 and 4.6 · SOC 2: CC6.3
ACC-02Access controlAnswered from policy
Does every user have a unique account, and are shared accounts allowed?
Our policies require every person to have a unique, individually attributable account. Shared accounts are prohibited except for documented break-glass credentials, which are stored in 1Password, restricted to the Security Owner and named engineering leads, used only when normal access is unavailable during an incident, and rotated after every use.
Source: Access Control Policy, section 4.2; Authentication and Password Policy, section 4.1 · SOC 2: CC6.1
ACC-03Access controlAnswered from policy
Do you use a central identity provider and single sign-on?
Yes. Okta is our single source of workforce identity. Our Access Control Policy requires business applications to be integrated with it for single sign-on and, where supported, automated provisioning and deprovisioning, and applications that cannot federate are recorded in an exception register with a compensating review.
Source: Access Control Policy, section 4.3; Authentication and Password Policy, section 4.3 · SOC 2: CC6.1, CC6.2
ACC-04Access controlAnswered from policy
How is access requested, approved and granted?
Our Access Control Policy requires access requests to be raised in our ticketing system naming the system and role, and to be approved by the requester's manager and the system owner before anything is provisioned. New hires receive the standard access bundle for their role through Okta, anything beyond it needs its own approved ticket, and the ticket is kept for seven years as the record of the grant.
Source: Access Control Policy, sections 4.5 and 5.1 · SOC 2: CC6.2
ACC-05Access controlAnswered from policy
How is access to production infrastructure controlled?
Our Access Control Policy grants production access on AWS and Vercel only to engineers whose role requires it, through federated identity and short-lived credentials rather than long-lived access keys. Administrators assume a separate privileged role for a session of no more than twelve hours, and its use is logged to Datadog. Production grants are approved by the engineering lead, and temporary grants carry an expiry date on which they are removed.
Source: Access Control Policy, sections 4.6 and 5.2 · SOC 2: CC6.1, CC6.3
ACC-06Access controlNeeds input
Who in your company can access customer data?
Our Access Control Policy limits direct access to customer data in production databases and storage to named engineers with a documented need, through audited tooling wherever possible, with every access logged. Because we process PII data, every direct query against customer data must be tied to a ticket or incident reference. [Fill in: how many people hold direct access to production customer data today, and their roles]
Source: Access Control Policy, section 4.7; Data Classification and Handling Policy, section 4.5 · SOC 2: CC6.1, C1.1
ACC-07Access controlAnswered from policy
How often do you review user access?
Our Access Control Policy requires access reviews at least quarterly for production, source code, identity administration and any system holding Restricted data, and at each annual review for all other systems. System owners attest to each account and privileged role, and removals are completed within five business days.
Source: Access Control Policy, sections 4.10 and 5.3 · SOC 2: CC6.2, CC6.3
ACC-08Access controlAnswered from policy
How do you manage service accounts, API keys and other non-human credentials?
Our Access Control Policy requires every non-human identity, such as a service account, API key, deploy key or integration token, to have a named human owner, a documented purpose, the narrowest permissions that fulfill it and an entry in our service account inventory. They are never used interactively, are rotated at least annually and immediately when a person who knew the secret leaves, and the inventory is checked in each quarterly access review.
Source: Access Control Policy, sections 4.9 and 5.5 · SOC 2: CC6.1
ACC-09Access controlAnswered from policy
How do you control access to your systems by vendors and other third parties?
Our Access Control Policy requires third-party access to be sponsored by a named employee, covered by a signed agreement with confidentiality terms, limited to the specific systems and time needed, provided through individual accounts with an expiry date, and removed at the end of the engagement.
Source: Access Control Policy, sections 4.12 and 5.7 · SOC 2: CC6.2, CC9.2
ACC-10Access controlAnswered from policy
How are administrator, root and break-glass accounts controlled?
Our Access Control Policy restricts accounts and tools that can bypass normal controls, such as the root or top-level administrator account of each platform on AWS and Vercel, to named engineers with a documented need. They are used only through time-bounded privileged roles or the break-glass process, never for routine work, and every use is logged to Datadog. Root or owner credentials are protected by hardware multi-factor authentication, and every break-glass use is recorded in an incident ticket, reviewed by the Security Owner and followed by a credential rotation within one business day.
Source: Access Control Policy, sections 4.13 and 5.6; Network and Infrastructure Security Policy, section 4.5 · SOC 2: CC6.3, CC6.1
MFA-01Authentication and MFAAnswered from policy
Is multi-factor authentication required for all employees?
Yes. Our Authentication and Password Policy requires multi-factor authentication for every workforce account, with no exception for seniority, and we enforce it through Okta. Administrative accounts use phishing-resistant methods such as FIDO2 security keys or passkeys.
Source: Authentication and Password Policy, section 4.2; Access Control Policy, section 4.4 · SOC 2: CC6.1
MFA-02Authentication and MFAAnswered from policy
Is multi-factor authentication required for administrative and production access?
Yes. Our Authentication and Password Policy requires multi-factor authentication for every administrative account and for all access to AWS and Vercel, GitHub and customer data. Administrators use phishing-resistant methods such as FIDO2 security keys or passkeys, and root or owner credentials are protected by hardware security keys. SMS and voice codes are permitted only where no other method is offered and are recorded as exceptions.
Source: Authentication and Password Policy, section 4.2; Network and Infrastructure Security Policy, section 4.5 · SOC 2: CC6.1
MFA-03Authentication and MFAAnswered from policy
What are your password requirements?
Our Authentication and Password Policy requires passwords chosen by people to be at least 14 characters, with no maximum below 64 and no forced character-class rules. Passwords are checked against known-breached password lists at creation and periodically, are not rotated on a fixed schedule, and are changed immediately when compromise is suspected or a password appears in a breach. Work passwords are never reused or shared.
Source: Authentication and Password Policy, sections 4.4 and 4.6 · SOC 2: CC6.1
MFA-04Authentication and MFAAnswered from policy
Do you use a password manager?
Yes. Our Authentication and Password Policy requires all work credentials to be generated and stored in 1Password, provisioned for every person at onboarding. Passwords may not be stored in browsers, spreadsheets, notes, chat or email.
Source: Authentication and Password Policy, section 4.5; Endpoint and Workstation Security Policy, section 4.9 · SOC 2: CC6.1
MFA-05Authentication and MFAAnswered from policy
How are user sessions and idle timeouts handled?
Our Authentication and Password Policy requires workforce sessions in Okta to expire after no more than 24 hours, privileged sessions on AWS and Vercel after no more than 12 hours, and devices to lock after 10 minutes of inactivity. Re-authentication is required for sensitive actions such as changing multi-factor settings or viewing secrets.
How do you verify identity before resetting a password or second factor?
Our Authentication and Password Policy allows account recovery and multi-factor resets only after identity is verified through a channel other than the one being recovered, such as a video call with a known colleague or a code sent to a verified personal contact. Requests that arrive by email or chat alone are never actioned. After a reset, sessions are revoked, any bypass code is valid for no more than one hour, a new factor must be enrolled before it expires, and recent sign-in activity is reviewed.
Source: Authentication and Password Policy, sections 4.10 and 5.4 · SOC 2: CC6.1, CC6.2
MFA-07Authentication and MFAAnswered from policy
How do you confirm that every account has multi-factor authentication enrolled?
Our Authentication and Password Policy requires the Security Owner to export multi-factor enrollment status every month from Okta, the identity services of AWS and Vercel and GitHub, and to open a ticket for any account without a valid method. Accounts still without one after five business days are suspended, and the export is kept as evidence.
Does your product support multi-factor authentication and single sign-on for customer users?
Our Authentication and Password Policy requires Northwind to offer multi-factor authentication to customers. [Fill in: the MFA methods Northwind supports, whether it supports SAML or OIDC single sign-on and on which plans, and whether customer administrators can require MFA for their users]
How are customer passwords stored in your application?
Our policies require passwords for Northwind accounts to be hashed with Argon2id, bcrypt or scrypt using a per-user salt and a work factor reviewed annually, never logged or sent in plain text, checked against breached-password lists, and never recoverable.
Source: Authentication and Password Policy, section 4.11; Encryption and Key Management Policy, section 4.8 · SOC 2: CC6.1
ENC-01Encryption and key managementAnswered from policy
Is data encrypted in transit, and which protocols do you allow?
Our Encryption and Key Management Policy requires TLS 1.2 or higher, with TLS 1.3 preferred, for data sent over public networks, between Northwind and its users, and between services across a network trust boundary. Public endpoints enforce HTTPS with HTTP Strict Transport Security, and SSL, TLS 1.0 and TLS 1.1 are prohibited.
Source: Encryption and Key Management Policy, sections 4.1 and 4.3 · SOC 2: CC6.7
ENC-02Encryption and key managementAnswered from policy
Is customer data encrypted at rest?
Our Encryption and Key Management Policy requires production data at rest on AWS and Vercel, including databases, object storage, volumes, snapshots, backups and log storage, to be encrypted with AES-256 or a provider-equivalent algorithm, turned on before any data is written. Stores holding customer data use keys held in the provider's key management service, never keys embedded in application code.
ENC-03Encryption and key managementAnswered from policy
How are encryption keys generated, stored and protected?
Our Encryption and Key Management Policy requires encryption keys to be generated inside the cloud provider's key management service or an equivalent hardware-backed service and never to leave it in plaintext. Application data uses envelope encryption with data keys wrapped by a root key. Key administration is restricted to named engineering roles, kept separate from key use by workloads, requires multi-factor authentication through Okta, and is logged and alerted on.
Source: Encryption and Key Management Policy, sections 4.4 and 4.7 · SOC 2: CC6.1
ENC-04Encryption and key managementAnswered from policy
How often are encryption keys and secrets rotated?
Our Encryption and Key Management Policy sets a rotation schedule: key management root keys at least annually with automatic rotation where supported, broadly privileged service credentials and API tokens every 90 days, other application secrets at least every 12 months, and any key or secret immediately when compromise is suspected or a person with direct access leaves or changes role.
Source: Encryption and Key Management Policy, sections 4.6 and 5.3 · SOC 2: CC6.1
ENC-05Encryption and key managementAnswered from policy
How do you store application secrets and credentials?
Our Encryption and Key Management Policy requires application secrets, service credentials and API tokens to live only in a designated secrets manager and to be injected at runtime. They are never committed to GitHub, printed in GitHub Actions logs, built into images or shared by chat or email, and the policy requires secret scanning and push protection on every repository in GitHub.
ENC-06Encryption and key managementAnswered from policy
Are laptops and mobile devices encrypted?
Our policies require full-disk encryption on every laptop and mobile device used for company work: FileVault on macOS, BitLocker on Windows, LUKS on Linux and platform encryption on mobile devices. The policies require encryption to be enforced and reported through Kandji, recovery keys to be escrowed there, and devices that fall short to be remediated within 7 days or blocked from company systems.
Source: Encryption and Key Management Policy, sections 4.9 and 5.7; Endpoint and Workstation Security Policy, section 4.4 · SOC 2: CC6.7
ENC-07Encryption and key managementAnswered from policy
Are backups encrypted?
Our Backup and Recovery Policy requires all backups to be encrypted at rest with AES-256 or stronger, using keys managed in the key management service of AWS and Vercel and kept separate from the keys protecting production data where the platform allows. Backups copied between accounts or regions are encrypted in transit.
[Fill in: whether Northwind supports customer-managed or customer-supplied encryption keys, and on which plans. If it does not, say so]
No policy covers this: answer from your own records. · SOC 2: CC6.1
ENC-09Encryption and key managementAnswered from policy
What happens if an encryption key or secret is exposed?
Our Encryption and Key Management Policy treats exposure of a key, secret or certificate private key as a security incident. The exposed material is revoked and rotated first, within four hours of the report for secrets found in source, logs or chat, and the exposure is then investigated: logs are checked for use of the exposed value, and data protected only by an exposed key is re-encrypted.
Source: Encryption and Key Management Policy, sections 4.13 and 5.5 · SOC 2: CC7.4, CC6.1
NET-01Network and infrastructureAnswered from policy
Are your production, staging and development environments separated?
Our Network and Infrastructure Security Policy requires production, staging and development to be isolated in separate accounts, projects or subscriptions with no shared network paths, credentials or data. Production data is not copied into non-production environments except as anonymized or synthetic datasets approved by the Security Owner.
Source: Network and Infrastructure Security Policy, section 4.1; Secure Software Development Policy, section 4.7 · SOC 2: CC6.1, CC8.1
NET-02Network and infrastructureAnswered from policy
How is your production network segmented and protected?
Our Network and Infrastructure Security Policy requires workloads on AWS and Vercel to sit in private segments with no direct inbound route from the internet, databases and caches to accept connections only from application segments, and firewall rules to default to deny. Data stores are never exposed to the public internet, and storage buckets are private by default with public access blocked at the account level.
Source: Network and Infrastructure Security Policy, sections 4.2 and 4.3 · SOC 2: CC6.6, CC6.1
NET-03Network and infrastructureAnswered from policy
Do you use a web application firewall and denial-of-service protection?
Our Network and Infrastructure Security Policy requires a web application firewall or equivalent edge protection in front of every public HTTP endpoint, and the provider's DDoS protection and edge rate limiting on public-facing services.
Source: Network and Infrastructure Security Policy, sections 4.2 and 4.11 · SOC 2: CC6.6
NET-04Network and infrastructureAnswered from policy
How do administrators access servers and cloud consoles?
Our Network and Infrastructure Security Policy grants administrative access only to named individuals through single sign-on from Okta with multi-factor authentication. Interactive access to servers and containers goes through the provider's session management service, an identity-aware proxy or a session-recording bastion. Inbound SSH and RDP from the internet are prohibited, and short-lived credentials replace static access keys wherever the platform supports them.
Source: Network and Infrastructure Security Policy, sections 4.5 and 4.6 · SOC 2: CC6.1, CC6.6
NET-05Network and infrastructureAnswered from policy
Is your infrastructure defined as code and change-controlled?
Our policies require infrastructure to be defined as code in GitHub, changed only through peer-reviewed pull requests and deployed through GitHub Actions. Manual console changes to production are limited to emergencies, are logged, and are reconciled into code within five business days, and monthly drift detection finds console changes so they can be reconciled or reverted.
NET-06Network and infrastructureAnswered from policy
Do you rely on a VPN or the office network to protect internal systems?
No. We operate a remote work model, and our Network and Infrastructure Security Policy treats no office or home network as trusted. Access depends on the identity and device of the person connecting, not on the network, and any corporate VPN is limited to specific administrative destinations.
Source: Network and Infrastructure Security Policy, section 4.12; Access Control Policy, section 4.12 · SOC 2: CC6.6
NET-07Network and infrastructureAnswered from policy
Is the production environment built to tolerate the failure of a data center or availability zone?
Our Business Continuity and Disaster Recovery Policy requires critical systems to be designed to survive the loss of a single availability zone or data center without exceeding their recovery time objective, using the redundancy features of AWS and Vercel, with infrastructure defined as code so environments can be rebuilt in another region or account. Our Network and Infrastructure Security Policy also requires production workloads to span at least two availability zones or equivalent failure domains.
Source: Business Continuity and Disaster Recovery Policy, section 4.3; Network and Infrastructure Security Policy, section 4.11 · SOC 2: A1.2, CC9.1
LOG-01Logging and monitoringAnswered from policy
Do you centrally collect security logs?
Our Logging and Monitoring Policy requires logs from every source to be forwarded to Datadog within 15 minutes of being generated. Sources include the audit logs of AWS and Vercel, Okta sign-in and administrator events, the GitHub organization audit log, GitHub Actions runs, and authentication, privileged-action and data-export events in Northwind.
Source: Logging and Monitoring Policy, sections 4.1 and 4.3 · SOC 2: CC7.2
LOG-02Logging and monitoringAnswered from policy
How long do you keep logs?
Our Logging and Monitoring Policy requires security and audit logs to be kept for at least 12 months, with the most recent 90 days searchable without restoration, and application debug logs for 30 days. Retention is set in platform configuration in Datadog and checked quarterly.
Source: Logging and Monitoring Policy, sections 4.4 and 5.7 · SOC 2: CC7.2
LOG-03Logging and monitoringAnswered from policy
How do you protect logs from tampering or deletion?
Our Logging and Monitoring Policy requires log storage to be append-only or to use provider immutability, deletion to happen only through the configured retention policy, and no individual, including administrators, to hold standing rights to delete or modify records. Disabling a source, changing retention or altering forwarding goes through change management and raises an alert, and access to logs is limited to engineering and the Security Owner and reviewed quarterly.
Source: Logging and Monitoring Policy, sections 4.5 and 4.6 · SOC 2: CC7.2
LOG-04Logging and monitoringAnswered from policy
Which security events generate alerts?
Our Logging and Monitoring Policy requires alert rules for at least: repeated authentication failures or credential stuffing; multi-factor authentication disabled or reset; a new administrator or privilege escalation; changes to cloud identity policies; use of a root, owner or break-glass account; a firewall rule opened to the internet; a storage bucket made public; a secret detected in GitHub; logging disabled; unusual data export or deletion volume; and changes to GitHub Actions configuration or deployment credentials; and a device falling out of compliance in Kandji. Each rule has a severity, an owner and a runbook.
Our Logging and Monitoring Policy sets triage targets: Critical alerts within 1 hour at any time, High within 4 business hours, Medium within 2 business days and Low at the weekly review. Any alert assessed as a confirmed or probable security event is escalated under our Incident Response Policy.
Our Logging and Monitoring Policy prohibits logging passwords, session tokens, API keys, private keys, full card numbers, health information and other sensitive data, and requires fields that could contain them to be masked before the log is written. Each record carries a UTC timestamp, the source system, the acting identity, the action, the target and the result.
How do you monitor the availability and performance of your service?
Our Logging and Monitoring Policy requires external uptime checks for every public Northwind endpoint from at least two locations, dashboards for error rate, latency and saturation, and alerts routed to the on-call engineer. It also requires service level objectives for availability and latency with alerts against them, and a customer-facing status page updated within 30 minutes of a confirmed customer-impacting outage. [Fill in: the address of your status page]
Source: Logging and Monitoring Policy, sections 4.9 and 5.9 · SOC 2: A1.1, CC7.2
LOG-08Logging and monitoringAnswered from policy
Are logs and alerts reviewed regularly?
Our Logging and Monitoring Policy requires the Security Owner or a delegate to review alert activity, privileged actions and log source health weekly, and detection coverage quarterly, with each review recorded. It also requires a semi-annual test that simulates a sample of alert conditions, such as a burst of failed logins, to confirm each alert reaches on-call in the expected time.
Source: Logging and Monitoring Policy, sections 4.10 and 5.10 · SOC 2: CC7.2, CC4.1
VUL-01Vulnerability managementAnswered from policy
How do you identify vulnerabilities in your systems and code?
Our Vulnerability and Patch Management Policy requires ongoing discovery from several sources: software composition and static analysis in GitHub Actions on every pull request and on a schedule, secret scanning in GitHub, container image scanning, the native security posture service of each platform on AWS and Vercel, endpoint patch reporting from Kandji, an annual independent penetration test, vendor advisories, the CISA Known Exploited Vulnerabilities catalog, and reports received through our disclosure channel.
VUL-02Vulnerability managementAnswered from policy
What are your timelines for fixing vulnerabilities?
Our Vulnerability and Patch Management Policy requires findings to be fixed within these timelines from detection: Critical within 7 days, High within 30 days, Medium within 90 days and Low within 180 days. Where no fix exists for a Critical finding in an internet-facing system, a mitigating control is applied within 72 hours. Severity starts from the CVSS base score and is adjusted for internet exposure, active exploitation and data sensitivity.
Source: Vulnerability and Patch Management Policy, sections 4.3 and 4.2 · SOC 2: CC7.1
VUL-03Vulnerability managementAnswered from policy
How often are servers, containers and endpoints patched?
Our Vulnerability and Patch Management Policy requires production container and machine images to be rebuilt from updated bases and redeployed at least monthly, with managed services on AWS and Vercel patched by the provider and maintenance notices tracked. Endpoints install critical and high operating system and browser security updates within 7 days of release and all others within 30 days, with automatic updates enforced through Kandji, and devices out of date for more than 7 days are blocked from company systems until remediated.
Source: Vulnerability and Patch Management Policy, section 4.4; Endpoint and Workstation Security Policy, section 4.6 · SOC 2: CC7.1, CC6.8
VUL-04Vulnerability managementNeeds input
Do you have independent penetration tests performed?
Our policies require an independent penetration test of Northwind at least annually and after major architectural changes. Findings are remediated on our standard timelines, and Critical and High findings are retested by the tester before closure. [Fill in: the date and provider of your most recent test. If you have not had one yet, say so and give the planned date]
Source: Secure Software Development Policy, section 4.12; Vulnerability and Patch Management Policy, section 4.12 · SOC 2: CC4.1, CC7.1
VUL-05Vulnerability managementNeeds input
Can you share the results of your most recent penetration test?
[Fill in: whether you can share an executive summary, a retest letter or the full report, and on what terms, for example under a non-disclosure agreement. If no test has taken place yet, say so]
No policy covers this: answer from your own records. · SOC 2: CC4.1
VUL-06Vulnerability managementAnswered from policy
Do you have a process for outside researchers to report vulnerabilities?
Our Vulnerability and Patch Management Policy requires us to publish a security contact, security@northwindcloud.example, and a security.txt file, to acknowledge good-faith reports within three business days, to work with reporters to validate and fix issues, and not to pursue legal action against researchers who act in good faith, respect user privacy and avoid service disruption.
VUL-07Vulnerability managementAnswered from policy
How do you respond when a critical zero-day vulnerability is announced?
Our Vulnerability and Patch Management Policy requires the Security Owner to convene engineering the same business day to assess exposure, apply mitigations and communicate status. Any vulnerability in the CISA Known Exploited Vulnerabilities catalog present in an internet-facing system is rated Critical, and confirmed exploitation is handled under our Incident Response Policy.
Source: Vulnerability and Patch Management Policy, sections 4.9 and 4.2 · SOC 2: CC7.1, CC7.4
VUL-08Vulnerability managementAnswered from policy
Do you run end-of-life or unsupported software in production?
Our Vulnerability and Patch Management Policy prohibits end-of-life or unsupported software in production. Engineering tracks support end dates for operating systems, runtimes, databases and major frameworks and begins migration at least 90 days before support ends.
VUL-09Vulnerability managementAnswered from policy
How often do you scan your internet-facing systems?
Our policies require internet-facing systems to be scanned at least quarterly and after significant changes, in addition to scanning in the build pipeline, and the external attack surface of Northwind to be checked for open ports and exposed services at least monthly.
Source: Vulnerability and Patch Management Policy, section 4.10; Network and Infrastructure Security Policy, section 4.13 · SOC 2: CC7.1
SDL-01Secure developmentAnswered from policy
Do you follow a secure software development lifecycle?
Our Secure Software Development Policy defines a secure development lifecycle: security requirements during planning, threat modeling during design, secure coding standards and peer review during implementation, automated and manual security testing before release, and monitoring and vulnerability management afterward.
Our Secure Software Development Policy requires written security requirements and a threat model approved by the Security Owner before work starts on any feature that adds or changes authentication, authorization, session handling, payment flows, file upload, third-party integrations, cryptography or the processing of sensitive data. The threat model documents data flows, trust boundaries and threats using a structured method such as STRIDE, and mitigations become tracked backlog items.
Source: Secure Software Development Policy, sections 4.2 and 5.1 · SOC 2: CC8.1, CC3.2
SDL-03Secure developmentAnswered from policy
Which secure coding standards do your engineers follow?
Our Secure Software Development Policy adopts OWASP ASVS Level 2 as the baseline for our secure coding standards and addresses the OWASP Top 10, including parameterized queries, output encoding, server-side input validation, centralized authentication and authorization checks, secure session management, protection against server-side request forgery, and vetted cryptographic libraries only.
What automated security testing runs in your build pipeline?
Our Secure Software Development Policy requires every pull request and the default branch to be scanned in GitHub Actions with static application security testing, software composition analysis, secret detection, container image scanning and infrastructure-as-code scanning. Critical and High findings block the merge until fixed or formally suppressed, and a suppression needs written justification and Security Owner approval and expires after 90 days.
Source: Secure Software Development Policy, sections 4.5 and 5.3 · SOC 2: CC8.1, CC7.1
SDL-05Secure developmentAnswered from policy
How do you manage open-source dependencies?
Our policies require dependencies to come only from official registries, to be pinned with lockfiles, and to be kept current through automated update pull requests. End-of-life, unmaintained or incompatibly licensed packages are not used, and dependencies with Critical or High vulnerabilities are updated within our remediation timelines. A software bill of materials for Northwind is generated from GitHub and GitHub Actions so that advisories can be matched to what is deployed.
Is production customer data used in development or testing?
Our policies prohibit copying production customer data into development, staging, test or analytics environments. Where realistic data is needed, engineering uses synthetic data or data irreversibly anonymized through a method approved by the Security Owner, and production secrets are never used in lower environments.
Source: Data Classification and Handling Policy, section 4.6; Secure Software Development Policy, section 4.7 · SOC 2: CC8.1, C1.1
SDL-07Secure developmentAnswered from policy
How do you secure the interfaces and APIs your product exposes?
Our Secure Software Development Policy requires every interface Northwind exposes to authenticate the caller, enforce object-level and function-level authorization on the server, validate input against a schema, apply rate limiting, return generic errors, and never place secrets or sensitive data in URLs. Web clients set a Content Security Policy, frame protection and secure, HttpOnly, SameSite cookies.
Source: Secure Software Development Policy, sections 4.9 and 4.10 · SOC 2: CC8.1, CC6.6
SDL-08Secure developmentAnswered from policy
How is security checked during code review?
Our policies require all code to be peer reviewed through a pull request in GitHub, with reviewers applying a security checklist that covers authorization, input handling, secrets, logging of sensitive data, error handling and dependency changes. Changes touching authentication, authorization, data access, cryptography, cloud permissions, network exposure or logging also need approval from the Security Owner or a designated security reviewer.
Yes. Our Change Management Policy requires every code and infrastructure change to go through a pull request in GitHub, classified as standard (pre-approved and low risk), normal or emergency. Production reflects only what has been merged to the protected branch, and editing code or configuration directly on servers or in cloud consoles is prohibited outside the emergency procedure.
Are code changes reviewed and approved by someone other than the author?
Our Change Management Policy requires branch protection in GitHub that needs at least one approving review from someone other than the author, dismisses stale approvals on new commits, blocks force pushes and applies to administrators without bypass, with self-approval disabled. Where team size leaves no qualified independent reviewer, the Security Owner or a technically competent member of Executive Management reviews; the requirement is never waived.
Our Change Management Policy requires every pull request to run the automated test suite, linting, dependency and static analysis scanning and a build in GitHub Actions, with failing checks blocking the merge. New functionality includes automated tests, changes are promoted through staging before production, and database migrations are tested in staging against representative data.
Our Change Management Policy allows production deployments only through GitHub Actions, using dedicated service identities scoped to the target environment. Personal credentials never deploy to production, each deployment record captures who triggered it, the commit deployed and the outcome, and vendors and contractors hold no standing write access to production.
Our Change Management Policy allows the engineering lead or the Security Owner to declare an emergency change when an active incident or imminent risk cannot wait for the normal process. A second engineer is notified before the change, the approval is recorded in the incident ticket and the change is labeled in GitHub. Within two business days it receives a full retrospective review, and it appears in the monthly change report.
How do you roll back a change that causes problems?
Our Change Management Policy requires every change to have a documented rollback path, such as reverting the merge, redeploying the previous artifact or turning off a feature flag. Rollback of high-risk changes is tested in staging first, and the deploying engineer watches error rates and key metrics in Datadog for at least 30 minutes after deployment and rolls back if the service degrades.
Do you notify customers before changes or planned maintenance?
Our Change Management Policy requires changes with potential customer impact to be communicated internally before deployment, and changes that involve downtime or changed behavior to be scheduled in an announced maintenance window and communicated to customers at least 48 hours in advance through the status page or release notes. Release notes are published for customer-visible changes.
How are changes to security settings that are not managed as code controlled?
Our Change Management Policy requires security-relevant configuration changes in systems not managed as code, such as organization settings in GitHub, Okta policies, vendor administration consoles and DNS, to be requested by ticket, approved by the Security Owner and recorded with the before and after state.
Yes. Our Incident Response Policy defines severity levels with acknowledgment targets, an Incident Commander for every SEV1 and SEV2 incident with authority to take systems offline and revoke credentials, an incident record with a timestamped timeline kept for seven years, evidence preservation before remediation, customer and regulatory notification, and a blameless post-incident review.
How should employees and customers report a security issue?
Security incidents and concerns can be reported to security@northwindcloud.example. Our Incident Response Policy requires anyone who observes or suspects a security incident to report it within one hour of discovery, and good-faith reports are never penalized, even when the reporter caused the problem.
How quickly will you notify us if our data is affected by a security incident?
Our Incident Response Policy requires us to notify affected customers without undue delay, within any contractual timeframe, and in every case within 72 hours of confirming their data was affected. The notice states what happened, what we have done and what the customer should do. [Fill in: the channel notices are sent through, for example email to the account's security contact]
Source: Incident Response Policy, section 4.8; Privacy and Data Protection Policy, section 4.11 · SOC 2: CC2.3, CC7.4
INC-04Incident responseAnswered from policy
How do you handle legal and regulatory breach notification?
Our Incident Response Policy requires legal, regulatory and contractual notification obligations to be assessed for every SEV1 and SEV2 incident, with outside counsel where the analysis is unclear. Where personal data is involved, it requires notice to supervisory authorities within 72 hours where the GDPR or UK GDPR applies, to affected individuals and state attorneys general where US state breach laws require it, and to customers acting as data controllers in time to meet their own deadlines.
Our Incident Response Policy requires the plan to be exercised at least annually with Executive Management, engineering and the Security Owner, using a scenario such as a leaked GitHub token, ransomware on a laptop or a compromised administrator account on AWS and Vercel, with findings entered in the risk register. All personnel complete incident-reporting training at onboarding and annually. [Fill in: the date of your last exercise, or of a real incident handled under the plan]
Our Incident Response Policy requires a blameless post-incident review within five business days of closing every SEV1 and SEV2 incident, producing a root cause, an impact statement and corrective actions with owners and due dates. Actions are tracked to closure and reported to Executive Management.
Have you had a security incident or data breach in the past three years?
[Fill in: whether you had a security incident in the past three years that required notifying customers or regulators. If yes, give a short description, the root cause and what changed afterward. If not, say so]
No policy covers this: answer from your own records. · SOC 2: CC7.4
INC-08Incident responseAnswered from policy
How do you handle security incidents at your vendors?
Our Incident Response Policy covers incidents at vendors that affect our data or Northwind, including incidents at Supabase, Stripe, Datadog and Slack. Vendor contracts must require notification to us within 72 hours, and any vendor breach notification is handled as an incident under the same policy.
Our Incident Response Policy puts protecting customer data and people ahead of restoring availability. The first containment actions are to rotate compromised credentials and revoke sessions in Okta, rotate exposed keys and secrets, block malicious addresses and isolate affected hosts or containers on AWS and Vercel, and to lock or wipe affected endpoints through Kandji. Compromised hosts are isolated, not rebuilt, until evidence is captured.
BCP-01Business continuity and disaster recoveryAnswered from policy
Do you have a business continuity and disaster recovery plan?
Yes. Our Business Continuity and Disaster Recovery Policy requires an annual business impact analysis that tiers each system supporting Northwind, recovery time and recovery point objectives for each tier approved by Executive Management, and a written recovery procedure for every Tier 1 and Tier 2 system that an engineer who did not build it can follow, stored in GitHub with an offline copy.
Source: Business Continuity and Disaster Recovery Policy, sections 4.1 and 4.2 · SOC 2: CC9.1, A1.2
BCP-02Business continuity and disaster recoveryNeeds input
What are your recovery time and recovery point objectives?
Our Business Continuity and Disaster Recovery Policy requires recovery time and recovery point objectives for each system tier, approved by Executive Management after the annual business impact analysis. [Fill in: the RTO and RPO for Northwind]
Source: Business Continuity and Disaster Recovery Policy, section 4.1 · SOC 2: A1.2, CC9.1
BCP-03Business continuity and disaster recoveryNeeds input
How often do you test disaster recovery?
Our Business Continuity and Disaster Recovery Policy requires critical systems to be restored at least annually from infrastructure code and backups into an isolated account or region, with achieved recovery times and data age recorded against the objectives, and the whole plan to be exercised at least annually through a tabletop with Executive Management. Every test is followed by a review within ten business days. [Fill in: the date and result of your last recovery test]
Source: Business Continuity and Disaster Recovery Policy, sections 4.10 and 4.13 · SOC 2: A1.3
BCP-04Business continuity and disaster recoveryAnswered from policy
How will you keep customers informed during a major outage?
Our Business Continuity and Disaster Recovery Policy requires customers to be kept informed through the status page or the channel committed in their contract, with an initial notice within 30 minutes of a disaster being declared and updates at least hourly while a critical system is disrupted. It also requires an alternative communication channel for our own team that does not depend on our primary systems.
Source: Business Continuity and Disaster Recovery Policy, sections 4.12, 5.6 and 4.8 · SOC 2: CC2.3, A1.2
BCP-05Business continuity and disaster recoveryNeeds input
Do you offer a contractual availability commitment?
[Fill in: whether you offer a service level agreement for Northwind, the commitment and how it is measured, and any service credits. If you do not offer one, say so]
No policy covers this: answer from your own records. · SOC 2: A1.1
BCP-06Business continuity and disaster recoveryAnswered from policy
Does your recovery plan depend on specific people or office locations?
Our Business Continuity and Disaster Recovery Policy requires that no critical recovery procedure depends on a single named individual, that at least one trained alternate exists for each role named in a recovery procedure, and that no production capability depends on physical access to an office. Because we operate a remote work model, losing any single workplace does not interrupt operations.
Source: Business Continuity and Disaster Recovery Policy, sections 4.14, 5.10 and 4.9 · SOC 2: CC9.1
BCP-07Business continuity and disaster recoveryAnswered from policy
How do you manage continuity risk from critical vendors?
Our policies require critical vendors, including Supabase, Stripe, Datadog and Slack where they support critical systems, to be assessed for continuity risk, and every critical dependency to have a documented exit or fallback plan covering a prolonged outage or the end of the relationship, including data retrieval and migration time. Reliance on a single vendor for a critical function is recorded in our risk register.
Source: Business Continuity and Disaster Recovery Policy, section 4.11; Vendor and Third-Party Risk Management Policy, section 4.10 · SOC 2: CC9.2, CC9.1
BAK-01BackupsAnswered from policy
Do you back up customer data, and how often?
Our Backup and Recovery Policy requires production databases to be backed up using AWS Backup on a daily schedule at minimum, with point-in-time recovery turned on wherever the database engine supports it, and new production data stores may not go live until their backup is configured and a first restore has been verified.
Source: Backup and Recovery Policy, sections 4.2 and 4.1 · SOC 2: A1.2
BAK-02BackupsNeeds input
Where are backups stored?
Our Backup and Recovery Policy requires at least one copy of every backup to be stored in a different account or region on AWS and Vercel from the system it protects, under separate credentials, so that one compromised credential, misconfiguration or region failure cannot destroy both production data and its backups. [Fill in: the regions your backups are kept in]
Are backups protected against deletion and ransomware?
Our Backup and Recovery Policy requires backups of critical data to be protected against deletion for their retention period through immutability, object lock, deletion protection or an equivalent control. Deleting backups outside the retention schedule requires Security Owner approval and is logged, and access to backup storage and restore operations is limited to engineers with a documented need, protected by multi-factor authentication and reviewed quarterly.
Source: Backup and Recovery Policy, sections 4.4 and 4.6 · SOC 2: A1.2, CC6.1
BAK-04BackupsNeeds input
How often do you test restoring from backups?
Our Backup and Recovery Policy requires restore tests at least quarterly for a sample of critical databases and storage, and a full restore of the critical environment at least annually as part of the disaster recovery test. Each test records what was restored, the backup age, the elapsed time, the verification performed and any defects. [Fill in: the date of your last successful restore test]
How long are backups kept, and how long does deleted data remain in them?
Our Data Retention and Disposal Policy requires backups to expire automatically no later than 35 days after creation through AWS Backup lifecycle settings. Deleted production data is fully purged once the last backup containing it expires, and backups are never restored to get around a deletion.
Source: Data Retention and Disposal Policy, section 4.4; Backup and Recovery Policy, section 4.9 · SOC 2: C1.2, A1.2
BAK-06BackupsAnswered from policy
Are backup failures monitored?
Our Backup and Recovery Policy requires every backup job to be monitored, with failures and missed jobs raising an alert in Datadog to the engineering on-call rotation within one hour. A critical backup that fails twice in a row is handled as a SEV2 incident, and backup status is reviewed every business day.
Source: Backup and Recovery Policy, sections 4.7 and 5.2 · SOC 2: A1.2, CC7.2
BAK-07BackupsAnswered from policy
How do you protect data held in third-party services?
Our Backup and Recovery Policy requires the backup commitments of vendors that hold our data, including Supabase, Stripe, Datadog and Slack, to be confirmed during vendor due diligence. Where a vendor holds the only copy of business-critical data, engineering exports that data at least quarterly to storage on AWS and Vercel.
Source: Backup and Recovery Policy, sections 4.11 and 5.8 · SOC 2: A1.2, CC9.2
VEN-01Vendor managementAnswered from policy
Do you have a third-party risk management program?
Yes. Our Vendor and Third-Party Risk Management Policy requires a vendor inventory recording each vendor's owner, service, the data shared and its classification, tier, contract and renewal dates, and last review. No vendor receives our data, system access or a connection to our accounts until it is in the inventory, tiered by the Security Owner and cleared through the due diligence for its tier.
Source: Vendor and Third-Party Risk Management Policy, sections 4.1 and 4.2 · SOC 2: CC9.2
VEN-02Vendor managementAnswered from policy
How do you assess a vendor's security before you start using it?
Our Vendor and Third-Party Risk Management Policy requires due diligence matched to the vendor's tier before any data or access is shared. For critical vendors the Security Owner reviews an independent assurance report covering the service, records any exceptions and the controls we must operate on our side, and documents the data flow and the vendor's own subprocessors. Free, trial and personal-account services follow the same rule.
Source: Vendor and Third-Party Risk Management Policy, sections 4.2 and 4.3 · SOC 2: CC9.2, CC3.2
VEN-03Vendor managementAnswered from policy
What security terms do you require in vendor contracts?
Our Vendor and Third-Party Risk Management Policy requires contracts with our critical and important vendors to include confidentiality obligations, security controls appropriate to the data, notification of incidents affecting our data within 72 hours of the vendor becoming aware, restrictions on subprocessors, return or deletion of data on termination, and a right to assurance evidence.
Our Vendor and Third-Party Risk Management Policy requires every critical and important vendor to be reviewed at least annually to confirm the service, data and tier are still accurate, obtain the current assurance report, check for incidents and material changes, confirm contract terms and decide whether the relationship continues. Between reviews it requires us to follow critical vendors' status pages, security advisories and subprocessor changes.
Source: Vendor and Third-Party Risk Management Policy, sections 4.8 and 4.9 · SOC 2: CC9.2
VEN-05Vendor managementAnswered from policy
What happens to vendor access and your data when a vendor relationship ends?
Our policies require us to revoke all of the vendor's access and credentials, retrieve the data we need, obtain written confirmation of deletion within the contractual period and update the vendor inventory. Vendors must be contractually bound to delete or return our data within 90 days after the service ends.
Source: Vendor and Third-Party Risk Management Policy, section 4.11; Data Retention and Disposal Policy, section 4.10 · SOC 2: CC9.2, C1.2
VEN-06Vendor managementAnswered from policy
Which hosting and infrastructure providers does your service run on?
Northwind runs on AWS and Vercel. We do not operate our own data centers. Our Physical and Remote Work Security Policy relies on our hosting providers' physical and environmental controls as described in their independent assurance reports, which our vendor policy requires us to review for critical vendors.
Source: Physical and Remote Work Security Policy, section 4.1; Vendor and Third-Party Risk Management Policy, section 4.3 · SOC 2: CC9.2, CC6.4
VEN-07Vendor managementAnswered from policy
Can employees connect third-party apps or browser extensions to company accounts?
Our Vendor and Third-Party Risk Management Policy prohibits connecting third-party applications, browser extensions or AI services to company accounts, or pasting confidential or customer data into them, unless the service is an approved vendor whose tier permits that data. Engineering reviews OAuth grants quarterly and revokes unapproved ones.
Third-party services we use include Supabase, Stripe, Datadog and Slack. [Fill in: which of these process customer data, with the purpose and data location of each, or a link to your subprocessor list] Our Privacy and Data Protection Policy requires us to maintain a published list of subprocessors.
Source: Privacy and Data Protection Policy, section 4.6 · SOC 2: CC9.2
SUB-02SubprocessorsNeeds input
Will you notify us before adding or changing a subprocessor?
Yes. Our Privacy and Data Protection Policy requires us to give customers advance notice of changes to our subprocessor list. [Fill in: the notice period and channel, for example 30 days' notice by email, and whether customers can object]
Source: Privacy and Data Protection Policy, section 4.6 · SOC 2: CC2.3, CC9.2
SUB-03SubprocessorsAnswered from policy
Do your subprocessors sign data processing agreements?
Our policies require every vendor that processes personal data on our behalf to sign a data processing agreement that meets the GDPR, UK GDPR and applicable US state privacy laws, covering subprocessor approval, help with data subject requests, breach notification and transfer safeguards. No vendor receives personal data before the agreement is in place and the vendor has been assessed.
Source: Vendor and Third-Party Risk Management Policy, section 4.5; Privacy and Data Protection Policy, section 4.5 · SOC 2: CC9.2
SUB-04SubprocessorsAnswered from policy
Do you pass your security and privacy obligations down to subprocessors?
Our Privacy and Data Protection Policy requires that, where we process personal data for customers, we do so only on the customer's documented instructions and flow down equivalent obligations to each subprocessor. Our vendor policy requires contracts with critical vendors to include confidentiality, security controls, 72-hour incident notification, subprocessor restrictions and deletion of data on termination.
Source: Privacy and Data Protection Policy, section 4.6; Vendor and Third-Party Risk Management Policy, section 4.4 · SOC 2: CC9.2
SUB-05SubprocessorsNeeds input
Where do your subprocessors store and process customer data?
Our Privacy and Data Protection Policy requires the hosting regions used for Northwind to be documented in our data inventory and disclosed to customers, and personal data to cross borders only under a lawful transfer mechanism such as an adequacy decision or standard contractual clauses. [Fill in: the countries or regions where each subprocessor stores or processes customer data]
Source: Privacy and Data Protection Policy, section 4.7 · SOC 2: CC9.2, C1.1
PRV-01Privacy and data protectionNeeds input
What types of customer data do you collect and process?
The customer data we process includes personal information (PII). Our Privacy and Data Protection Policy requires a data inventory listing each category of personal data with its purpose, source, systems, recipients and retention period. [Fill in: the categories of customer data Northwind stores and the data this customer is expected to send]
Source: Privacy and Data Protection Policy, section 4.1 · SOC 2: C1.1
PRV-02Privacy and data protectionNeeds input
Where is customer data stored?
Our Data Classification and Handling Policy requires customer data to be stored only in the production environment of Northwind on AWS and Vercel and its managed backups, never on endpoints, in chat or tickets, in personal storage or in unapproved tools. Our Privacy and Data Protection Policy requires the hosting regions to be documented and disclosed to customers. [Fill in: the countries or cloud regions where customer data and backups are stored]
Source: Data Classification and Handling Policy, section 4.3; Privacy and Data Protection Policy, section 4.7 · SOC 2: C1.1
PRV-03Privacy and data protectionNeeds input
Do you publish a privacy notice?
Our Privacy and Data Protection Policy requires a published privacy notice that describes in plain language what personal data we collect, why, on what basis, with whom it is shared, how long it is kept, where it is stored, and how individuals can exercise their rights and contact us. [Fill in: the address of your privacy notice]
Source: Privacy and Data Protection Policy, section 4.12 · SOC 2: CC2.3
PRV-04Privacy and data protectionAnswered from policy
How do you handle requests from individuals to access or delete their data?
Our Privacy and Data Protection Policy requires us to honor requests to access, correct, erase, restrict, port or object to the processing of personal data, and to withdraw consent. We verify the requester's identity, respond within 30 days or any shorter legal deadline, and log every request and its outcome. Requests from a customer's end users are referred to that customer, and we help them respond.
Source: Privacy and Data Protection Policy, section 4.4 · SOC 2: CC2.3
PRV-05Privacy and data protectionNeeds input
Do you act as a data controller or a data processor for customer data?
Our Privacy and Data Protection Policy requires our data inventory to record, for each processing activity, whether we act as controller or processor. Where we act as a processor for customers, we process personal data only on the customer's documented instructions. [Fill in: your role for this customer's data, usually processor for the data customers put into Northwind]
Source: Privacy and Data Protection Policy, sections 4.1 and 4.6 · SOC 2: CC2.3, C1.1
PRV-06Privacy and data protectionAnswered from policy
How do you handle international transfers of personal data?
Our Privacy and Data Protection Policy allows personal data to cross national borders only where a lawful transfer mechanism applies, such as an adequacy decision or standard contractual clauses, and requires our hosting regions to be documented and disclosed to customers. Data processing agreements with our vendors must include transfer safeguards.
Source: Privacy and Data Protection Policy, section 4.7; Vendor and Third-Party Risk Management Policy, section 4.5 · SOC 2: C1.1
PRV-07Privacy and data protectionNeeds input
Will you sign a data processing agreement with us?
[Fill in: whether you offer a standard data processing agreement or will review the customer's, and where it can be found] As a processor, our Privacy and Data Protection Policy requires us to act only on documented customer instructions, keep a published subprocessor list with advance notice of changes, and notify affected customers of a breach within their contractual period and no later than 72 hours after confirmation.
Source: Privacy and Data Protection Policy, sections 4.6 and 4.11 · SOC 2: CC2.3
PRV-08Privacy and data protectionAnswered from policy
Do you process health information or payment card data?
We do not knowingly process health information through Northwind, and our policies require a privacy impact assessment and any needed contractual terms before that could change. We do not handle payment card data directly: payments go through a third-party processor, and our policies prohibit our systems from storing full card numbers or security codes.
Source: Data Classification and Handling Policy, sections 4.9 and 4.10; Privacy and Data Protection Policy, sections 4.8 and 4.9 · SOC 2: C1.1
PRV-09Privacy and data protectionAnswered from policy
How do you classify data?
Our Data Classification and Handling Policy defines four levels: Public, Internal, Confidential and Restricted. All customer data processed by Northwind, all PII data, credentials, encryption keys and security incident details are Restricted, which requires encryption at rest and in transit, access limited to people with a documented need, quarterly access review and logged access.
Source: Data Classification and Handling Policy, sections 4.1, 4.4 and 4.5 · SOC 2: C1.1
PRV-10Privacy and data protectionAnswered from policy
How do you apply data minimization and privacy by design?
Our Privacy and Data Protection Policy limits personal data to what is necessary for the purpose. Features of Northwind collect the minimum data needed, default to the most privacy-protective setting and let customers export and delete the data they submit, and new features and processing activities are assessed for privacy risk before launch, with a documented privacy impact assessment where the risk to individuals is likely to be high.
Source: Privacy and Data Protection Policy, section 4.3 · SOC 2: C1.1
PHY-01Physical and remote workAnswered from policy
Do you operate your own data centers or server rooms?
No. Our Physical and Remote Work Security Policy requires all production systems for Northwind to run in facilities operated by AWS and Vercel, and relies on those providers' physical and environmental controls, such as access control, surveillance, power, cooling and fire suppression, as described in their independent assurance reports. No production system or production data may be hosted on equipment in an office or a home.
Source: Physical and Remote Work Security Policy, section 4.1 · SOC 2: CC6.4, A1.2
PHY-02Physical and remote workNeeds input
How is physical access to your offices controlled?
We operate a remote work model. Where we maintain an office, our Physical and Remote Work Security Policy restricts entry to authorized personnel through keys, badges or a managed access system, issued at onboarding and revoked on the last working day, keeps doors locked outside staffed hours, and requires visitors to sign in and be escorted at all times. [Fill in: your office locations, or say that you have none]
Source: Physical and Remote Work Security Policy, sections 4.2 and 4.3 · SOC 2: CC6.4
PHY-03Physical and remote workAnswered from policy
What security requirements apply to people working outside the office?
Our Physical and Remote Work Security Policy requires a home workspace where screens cannot be seen by household members or visitors during work with company or customer information, headphones for calls that could be overheard, home Wi-Fi protected with WPA2 or WPA3 and a non-default password, and company devices used only by the person they are assigned to. Access to company systems depends on the identity and device of the person connecting, not on the network.
Source: Physical and Remote Work Security Policy, sections 4.6 and 4.7; Network and Infrastructure Security Policy, section 4.12 · SOC 2: CC6.6, CC6.4
PHY-04Physical and remote workAnswered from policy
May staff access production systems from public Wi-Fi?
Only through a protected connection. Our Physical and Remote Work Security Policy prohibits access to production systems, administrative consoles or customer data from public or untrusted networks unless the connection goes through the company VPN or an identity-aware proxy that encrypts all traffic and verifies the device, and prefers a personal hotspot to open public Wi-Fi.
Source: Physical and Remote Work Security Policy, section 4.8 · SOC 2: CC6.6
PHY-05Physical and remote workAnswered from policy
Do you have a clear desk and clear screen requirement?
Yes. Our Physical and Remote Work Security Policy requires screens to be locked whenever a device is left unattended, documents with company or customer information to be kept off desks, whiteboards to be wiped after confidential meetings, and printed confidential material to be collected immediately and shredded when no longer needed. Company devices are never left unattended in public places or vehicles.
Source: Physical and Remote Work Security Policy, sections 4.4 and 4.5 · SOC 2: CC6.4
PHY-06Physical and remote workAnswered from policy
How do you dispose of paper records and hardware that held company data?
Our policies require paper to be destroyed by cross-cut shredding or an accredited destruction service, and storage media and devices to be wiped to a secure-erase standard or physically destroyed by an accredited provider, with a record of the wipe or destruction kept. Confidential material never goes into general waste or recycling.
Source: Physical and Remote Work Security Policy, section 4.11; Endpoint and Workstation Security Policy, section 4.13; Data Retention and Disposal Policy, section 4.7 · SOC 2: CC6.5
END-01Endpoint securityAnswered from policy
Do you use mobile device management (MDM) for company devices?
Yes. Company endpoints are managed with Kandji. Our Endpoint and Workstation Security Policy requires every company endpoint to be enrolled before it is issued, does not allow users to remove the enrollment, and uses Kandji to enforce the encryption, screen lock, update and malware protection settings and to report compliance to the Security Owner.
Our Endpoint and Workstation Security Policy requires every laptop and desktop to run built-in or company-approved endpoint protection with real-time malware scanning and the host firewall turned on, with alerts reviewed by the Security Owner and forwarded to Datadog where the tooling supports it. Browsers keep their built-in protection against malicious and phishing sites turned on, and where Kandji supports it a DNS or web filtering profile blocks known malicious domains.
How are operating system and browser updates managed on endpoints?
Our Endpoint and Workstation Security Policy requires operating system and browser updates to install automatically, enforced through Kandji, with critical and high security updates applied within 7 days of release and all others within 30 days. Endpoints running an operating system that no longer receives security updates may not access company systems.
Source: Endpoint and Workstation Security Policy, sections 4.6 and 4.3 · SOC 2: CC7.1, CC6.8
END-04Endpoint securityAnswered from policy
Can personal devices be used to access company or customer data?
Our Endpoint and Workstation Security Policy permits access to production, source code and customer data only from company-owned endpoints, or from personally owned endpoints the Security Owner has explicitly approved that meet every endpoint requirement. A personal device may not be used for production access unless it is enrolled in Kandji to the same standard as a company device, and personal devices may be used for email and chat only with Security Owner approval.
Source: Endpoint and Workstation Security Policy, section 4.1; Acceptable Use Policy, section 4.4 · SOC 2: CC6.1, CC6.6
END-05Endpoint securityAnswered from policy
Is customer data stored on employee laptops?
Our Endpoint and Workstation Security Policy prohibits storing customer data and production datasets on endpoints. Where a task needs a local copy, it is limited to the minimum data, kept only for the task and deleted when the task is done, and production database dumps, backups and exports are never downloaded to a laptop.
Is the use of USB drives and other removable media restricted?
Our Endpoint and Workstation Security Policy prohibits using removable media such as USB drives, external disks or SD cards to store or move company or customer data; files move through approved cloud storage instead. Where Kandji supports it, writing to removable media is blocked by policy.
What happens when a laptop or phone is lost or stolen?
Our policies require the loss, theft or suspected compromise of any endpoint to be reported to security@northwindcloud.example within one hour of discovery. The Security Owner then locks and wipes the device remotely through Kandji, revokes the person's sessions, rotates any credentials that were on the device and handles the event under our Incident Response Policy. Full-disk encryption is required on every device.
Do users have local administrator rights on their devices?
Our Endpoint and Workstation Security Policy requires personnel to work from a standard user account. Local administrator rights are granted only where a role requires them, recorded in the device inventory and reviewed quarterly, software is installed only from official vendor sources or app stores, and browser extensions that can read page content need Security Owner approval.
RET-01Data retention and disposalAnswered from policy
How long do you retain customer data?
Our Data Retention and Disposal Policy requires customer data in Northwind to be kept for the term of the customer agreement and deleted within 30 days after it ends or after a verified written deletion request, unless a legal hold applies. Data is kept no longer than its business purpose, contract or legal obligation requires.
Source: Data Retention and Disposal Policy, sections 4.3 and 4.1 · SOC 2: C1.2
RET-02Data retention and disposalNeeds input
What happens to our data when our contract ends?
Our Data Retention and Disposal Policy requires the account to enter a read-only export state for 30 days after the agreement ends. After that, customer data is deleted from production, deletion is triggered at the subprocessors that hold it, and backups containing it expire on the backup schedule. We confirm deletion in writing on request. [Fill in: how customers export their data during the 30 days, for example a self-serve export or a request to support]
Source: Data Retention and Disposal Policy, sections 5.4 and 4.3 · SOC 2: C1.2
RET-03Data retention and disposalAnswered from policy
How do you securely delete data and dispose of storage media?
Our Data Retention and Disposal Policy requires electronic data to be disposed of by cryptographic erasure, provider-level deletion followed by expiry of associated snapshots, or overwriting, so that it cannot be reconstructed with commercially reasonable effort. Media leaving our control is purged or destroyed following NIST SP 800-88, devices are fully erased before reassignment or recycling using the remote erase function in Kandji, and each disposal of Confidential or Restricted data or hardware is recorded in a disposal log.
Source: Data Retention and Disposal Policy, sections 4.7, 4.8 and 4.12 · SOC 2: C1.2, CC6.5
RET-04Data retention and disposalAnswered from policy
Can we request deletion of our data, and will you confirm it?
Yes. Our Data Retention and Disposal Policy requires deletion requests from an authorized customer representative to be verified, ticketed and completed in production within 30 days, with a check that no copies remain in non-production environments, and deletion to be confirmed to the customer in writing.
Source: Data Retention and Disposal Policy, sections 5.3 and 4.3 · SOC 2: C1.2
RET-05Data retention and disposalAnswered from policy
Do you have a documented data retention schedule?
Yes. Our Data Retention and Disposal Policy includes a written retention schedule listing each data category, its system of record, retention period and disposal method: for example, customer data for the agreement term plus 30 days, backups for 35 days, security and audit logs for 12 months, and support tickets for three years after closure. The policy requires automated deletion rules to be checked each quarter.
Source: Data Retention and Disposal Policy, sections 4.1, 5.1 and 5.2 · SOC 2: C1.2
RET-06Data retention and disposalAnswered from policy
How long do you keep security logs and audit records?
Our Data Retention and Disposal Policy requires security and audit logs to be retained for 12 months, application debug logs for 30 days, and incident records, risk assessments, access reviews, policy approvals and audit evidence for seven years, unless a legal hold or documented investigation requires longer.
Source: Data Retention and Disposal Policy, sections 4.5 and 5.1 · SOC 2: C1.2, CC7.2
AI-01AI useAnswered from policy
Do your employees use generative AI tools, and how is that controlled?
Our Acceptable Use Policy allows AI assistants and code generation tools only if they are on our approved tool list. Before a tool is approved, the Security Owner reviews its data retention, training-use and subprocessor terms, records the data classifications it may receive, and arranges single sign-on through Okta where supported. The list is checked again each quarter.
Source: Acceptable Use Policy, sections 4.6 and 5.3 · SOC 2: CC5.3, CC9.2
AI-02AI useAnswered from policy
Is customer data entered into AI tools?
Our Acceptable Use Policy prohibits entering customer data, secrets, personal data or unreleased source code into any AI tool unless the Security Owner has confirmed in writing that the tool's data handling terms permit it. Our vendor policy also prohibits connecting AI services to company accounts unless they are approved vendors whose tier permits that data.
Source: Acceptable Use Policy, section 4.6; Vendor and Third-Party Risk Management Policy, section 4.12 · SOC 2: C1.1, CC9.2
AI-03AI useNeeds input
Is our data used to train AI models?
Our Acceptable Use Policy requires the training-use terms of every AI tool to be reviewed before approval, and prohibits putting customer data into any AI tool whose terms have not been confirmed in writing to permit it. [Fill in: whether Northwind or any of your AI vendors uses customer data to train or improve models, and whether customers can opt out]
Source: Acceptable Use Policy, sections 5.3 and 4.6 · SOC 2: C1.1
AI-04AI useAnswered from policy
Is code written with AI assistants reviewed before it ships?
Our Secure Software Development Policy requires code generated by AI assistants or copied from external sources to be reviewed to the same standard as human-written code, through the same pull request review and automated security scanning in GitHub Actions. Secrets, customer data and unreleased proprietary code are never submitted to unapproved AI tools.
Source: Secure Software Development Policy, sections 4.12 and 4.5 · SOC 2: CC8.1
AI-05AI useNeeds input
Does your product use AI or machine-learning features that process customer data?
[Fill in: whether Northwind includes AI or machine-learning features, which model providers they use, what customer data they process, whether the provider retains that data, and whether customers can turn the features off] Any AI provider that receives customer data is a vendor under our Vendor and Third-Party Risk Management Policy and must be assessed before it receives data.
From your policies. “Our Access Control Policy requires access reviews at least quarterly for production …”, with the policy and section named, so the answer matches the document an auditor or a customer may ask to see.
From your generator answers. Your hosting, identity provider, MFA status, device management, password manager, logging and backup tools, data types, vendors, owners and security contact.
Left for you. Report status, penetration test and restore test dates, recovery objectives, data regions, subprocessor details, product features such as SSO, and incident history.
The questions are Policyseed’s own. Their topics overlap with what common security questionnaires ask, so most customer questions map to one or two entries here, but the wording is not taken from any published questionnaire.
Other ways to answer questionnaires
Upload a customer’s questionnaire: when the customer sends a spreadsheet, this tool (included with the Audit Kit and Agency keys) matches each of their questions to your policies and fills in their workbook.
Security questionnaire answers: a shorter vendor questionnaire with editable answers, for when you need one complete document to send.
Trust page generator: a public security page answers many of these questions before they are asked, and often shortens the questionnaire you receive.
Audit Kit: the paid kit includes this library as an Excel workbook and a Markdown file, built from your tailored policies, in its questionnaire folder.
Frequently asked questions
Where do the answers come from?
From the 23 answers you gave the Policyseed generator and the 22 policies generated from them. Each answer states what one or more of those policies require and names the policy and section, so a reviewer can check it. Facts the generator never asked about, such as report status, test dates, recovery objectives, data regions or office locations, are left as [Fill in: ...] placeholders. No AI writes or rewrites the answers; the same answers always produce the same text.
Are these questions copied from a standard questionnaire?
No. The questions are written in Policyseed's own words. They cover the topics that common security questionnaires ask about, such as MFA, encryption, access reviews, vulnerability management, incident notification, backups, vendors and subprocessors, so the right answer is usually easy to find, but they do not reproduce any published questionnaire. When a customer sends their own form, search this library for the topic and adjust the wording to their question.
Can I paste the answers as they are?
Not without reading them. Every answer you send is a statement your customer may rely on and may write into the contract. Replace each placeholder, delete anything you do not do today, and remember that an answer citing a policy is only accurate if you have adopted that policy and follow it. A policy shows what you require, not that a control operates.
What if MFA is not enforced everywhere yet, or we have no device management?
The answers follow what you told the generator. If MFA is not yet enforced for every account, the MFA answers describe what your policy requires today (MFA for administrators, production, source code and customer data) and the dated rollout plan, with a placeholder for the completion date. If you have no MDM, the device answers say so and describe the written baseline and quarterly attestation your policy uses instead. Change your answers in the generator and this page updates.
Why do some answers say Needs input?
An answer is marked Needs input when it still holds a [Fill in: ...] placeholder, or when no policy covers the question. Use the Needs input only filter to work through them once, then keep your completed copy of the spreadsheet as your own answer library.
Is anything I type sent to a server?
No. Your generator answers are read from this browser's local storage, the answers are built in your browser, and the Excel and Markdown files are built in your browser too. Without saved answers the page shows the sample company, Northwind Cloud Inc.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.