Golden examples are what the passport offers as evidence that the agent does what
it says. Your rebuild is checked against these. This site checked the file's format, not the truth
of its examples.
These are templates of shape, never expected content. Whoever installs this runs it on their own questionnaire and their own documents, and different content is the correct result. Nothing was elided; the example below is the run's whole output, with only the scrub markers changed.
> This run answered a 12-question vendor security questionnaire, uploaded as one file, for a fictional vendor, "Brindlewood Software AG". Its approved documents were five invented documents written for that vendor (a company fact sheet, a subprocessor list, a privacy notice, a support and service-level policy and a security overview); every company fact, product name, place and number in the answers comes from those invented documents and describes no real company. It ran on the original's deep tier, the 122B-class model. Slot answers this run instantiated: answer length was medium; escalation owners were four roles at the fictional vendor, given as roles only (Security: CTO; Privacy: Data Protection Lead; Legal: Head of Legal and Finance; Default: Head of Operations); no past answers and no knowledge-base pages were supplied, so every Prior answer reads "None found"; terminology was empty and the source hierarchy was the default. Two contact addresses of the fictional vendor are replaced by [SCRUBBED:EMAIL] markers (three occurrences), and every real provider or product name the invented documents gave as the vendor's hosting, email, billing, support, analytics and key-management suppliers is replaced by [SCRUBBED:PROVIDER] (ten occurrences, in answers 2.2, 2.4 and 3.2), so the example implies no contract between a real company and a vendor that does not exist. The output has three known faults, kept verbatim so the example stays a real output: answer 3.3 says the product does not store passwords and then that it stores them as Argon2id hashes; answer 4.2 quotes only the Enterprise plan's SLA; and 4.2, which asks about a liability limit and insurance, was classified Commercial and routed to the default owner rather than to Legal. Treat the example as a template of shape only; none of the checks in section 3 depends on these faults.
Captured 2026-09-28:
## Draft answers
### 1.1 State your company's legal name, registered location, and the contact point for security and privacy matters.
**Draft answer:** Our legal name is Brindlewood Software AG, a Swiss stock corporation registered in the commercial register of the Canton of Lucerne, with its registered office in Lucerne, Switzerland [S1]. For security matters, please contact [SCRUBBED:EMAIL]; for privacy and data protection matters, contact [SCRUBBED:EMAIL] [S1].
**Evidence status:** Supported: current documentation
**Sources:** [S1]
**Prior answer:** None found
**Domain and risk:** Company, low
**Owner / reviewer:** Head of Operations, Brindlewood
**Clarification needed:** None
### 1.2 Is the product generally available, or in beta? Which parts of the offering are production services?
**Draft answer:** Brindlewood Forms is generally available and is a production service covered by our Support and Service Level Policy [S3]. Brindlewood Insights is currently in beta; beta features are offered without a service level and may change without notice [S3].
**Evidence status:** Supported: current documentation
**Sources:** [S3]
**Prior answer:** None found
**Domain and risk:** Product, medium
**Owner / reviewer:** Head of Operations, Brindlewood
**Clarification needed:** None
### 2.1 Under which data protection laws do you process personal data, and what is your lawful basis for processing?
**Draft answer:** We process personal data under the Swiss Federal Act on Data Protection (FADP) and, where applicable, the EU General Data Protection Regulation (GDPR) [S4]. For customer content processed as a processor, our basis is the customer's documented instructions under our Data Processing Agreement [S4]. For account and billing data where we act as controller, the basis is contract performance and legitimate interest in security logging [S4]. For our marketing newsletter, the basis is consent [S4].
**Evidence status:** Supported: current documentation
**Sources:** [S4]
**Prior answer:** None found
**Domain and risk:** Privacy, high
**Owner / reviewer:** Data Protection Lead, Brindlewood
**Clarification needed:** None
### 2.2 List all subprocessors that process personal data on your behalf, what each one does, and where they are based.
**Draft answer:** Our subprocessors are: [SCRUBBED:PROVIDER] ([SCRUBBED:PROVIDER]) for hosting and storage in Switzerland; [SCRUBBED:PROVIDER] ([SCRUBBED:PROVIDER]) for transactional email in the European Union; [SCRUBBED:PROVIDER] for billing in the European Union and United States; and [SCRUBBED:PROVIDER] for customer support in the European Union [S2]. Customer form responses and uploads are processed exclusively by [SCRUBBED:PROVIDER] in Switzerland [S2].
**Evidence status:** Supported: current documentation
**Sources:** [S2]
**Prior answer:** None found
**Domain and risk:** Privacy, high
**Owner / reviewer:** Data Protection Lead, Brindlewood
**Clarification needed:** None
### 2.3 How long do you retain personal data, and how can a data subject request access or deletion?
**Draft answer:** Customer content is retained for the duration of the contract and deleted within 30 days of termination, with backups overwritten within 35 days [S8]. Account and billing records are kept for 10 years per Swiss accounting law, and security logs are retained for 12 months [S8]. Data subjects can request access, correction, or erasure by writing to [SCRUBBED:EMAIL]; we respond within 30 days, or forward processor requests to the customer controller [S8].
**Evidence status:** Supported: current documentation
**Sources:** [S8]
**Prior answer:** None found
**Domain and risk:** Privacy, high
**Owner / reviewer:** Data Protection Lead, Brindlewood
**Clarification needed:** None
### 2.4 Does your public website use cookies, analytics scripts or third-party tracking?
**Draft answer:** Our website sets one strictly necessary cookie to remember a visitor's language [S8]. We use [SCRUBBED:PROVIDER] for measuring visits, which does not use cookies or collect personal data [S8]. We do not use advertising or third-party tracking scripts [S8].
**Evidence status:** Supported: current documentation
**Sources:** [S8]
**Prior answer:** None found
**Domain and risk:** Privacy, medium
**Owner / reviewer:** Data Protection Lead, Brindlewood
**Clarification needed:** None
### 3.1 Do you hold ISO 27001 certification or a SOC 2 Type II report? Attach the current certificate or report.
**Draft answer:** Current documentation does not confirm that Brindlewood holds ISO 27001 certification or a SOC 2 Type II report [S6, S9]. We conduct an independent penetration test annually, with the most recent completed in March 2026, and a summary letter is available under NDA [S9].
**Evidence status:** Not supported: no current evidence
**Sources:** [S6, S9]
**Prior answer:** None found
**Domain and risk:** Security, high
**Owner / reviewer:** CTO, Brindlewood
**Clarification needed:** Please confirm if the company holds ISO 27001 or SOC 2 Type II certification and provide the relevant certificate or report if available.
### 3.2 Do you encrypt customer data at rest and in transit? State the algorithms and key management approach.
**Draft answer:** Yes, we encrypt all connections to the application and API using TLS 1.2 or higher, with TLS 1.0 and 1.1 disabled and HSTS enabled [S6]. Data at rest in databases and file storage is encrypted using AES-256 with [SCRUBBED:PROVIDER]-managed encryption, and backups are encrypted similarly [S6]. Encryption keys are held in [SCRUBBED:PROVIDER], with an option for Enterprise customers to supply their own customer-managed keys for file storage [S6].
**Evidence status:** Supported: current documentation
**Sources:** [S6]
**Prior answer:** None found
**Domain and risk:** Security, high
**Owner / reviewer:** CTO, Brindlewood
**Clarification needed:** None
### 3.3 Do credentials, API keys or passwords belonging to our users pass through or get stored by your product?
**Draft answer:** We do not store or pass through user passwords, API keys, or credentials belonging to our customers. User passwords are stored only as Argon2id hashes, and API keys are shown once upon creation and then stored only as hashes [S9]. For third-party integrations, we do not ask for customer credentials; instead, we use OAuth tokens which are encrypted at rest and can be revoked by the customer at any time [S9].
**Evidence status:** Supported: current documentation
**Sources:** [S9]
**Prior answer:** None found
**Domain and risk:** Security, high
**Owner / reviewer:** CTO, Brindlewood
**Clarification needed:** None
### 3.4 Describe your incident response process and your breach notification timeline to customers.
**Draft answer:** Current documentation does not describe a specific incident response process or a defined breach notification timeline for customers. While we maintain security logs for 12 months and perform annual penetration testing [S9], the sources provided do not outline the steps taken during an incident or the timeframe for notifying customers of a breach.
**Evidence status:** Not supported: no current evidence
**Sources:** None
**Prior answer:** None found
**Domain and risk:** Security, high
**Owner / reviewer:** CTO, Brindlewood
**Clarification needed:** Please provide the documented incident response process and the specific timeline (e.g., hours or days) for breach notification to customers.
### 4.1 Do you support single sign-on (SAML 2.0 or OIDC) and role-based access control for Enterprise workspaces, and how is one customer's workspace data kept separate from another's?
**Draft answer:** Yes, we support Single Sign-On (SAML 2.0) and role-based access control (RBAC) for Enterprise workspaces. SAML 2.0 is available on the Enterprise plan, though OpenID Connect is not supported [S7]. Our RBAC includes four built-in roles (Owner, Admin, Editor, Viewer), with Admins able to restrict forms to specific users or groups [S7]. To ensure data separation, Brindlewood Forms is a multi-tenant service where each customer is a separate tenant; access is enforced by row-level security policies in the database, and file uploads are stored in a separate storage container per tenant [S7].
**Evidence status:** Supported: current documentation
**Sources:** [S7]
**Prior answer:** None found
**Domain and risk:** Product, medium
**Owner / reviewer:** Head of Operations, Brindlewood
**Clarification needed:** None
### 4.2 What is your uptime SLA, your standard limitation of liability, and do you carry cyber liability insurance?
**Draft answer:** For the Enterprise plan, we offer a 99.9% monthly availability SLA for the Brindlewood Forms application and API, with service credits as the sole remedy for missed availability [S5]. Our standard limitation of liability is not explicitly detailed in the provided sources, though the SLA policy states that service credits are the customer's sole remedy for availability issues [S5]. Current documentation does not confirm whether we carry cyber liability insurance.
**Evidence status:** Partly supported
**Sources:** [S5]
**Prior answer:** None found
**Domain and risk:** Commercial, high
**Owner / reviewer:** Head of Operations, Brindlewood
**Clarification needed:** Please confirm the standard limitation of liability clause and provide evidence of cyber liability insurance coverage.
## Unresolved and high-risk items
- **2.1** Under which data protection laws do you process personal data, and what is your lawful... (Privacy). high risk. Owner: Data Protection Lead, Brindlewood.
- **2.2** List all subprocessors that process personal data on your behalf, what each one does, a... (Privacy). high risk. Owner: Data Protection Lead, Brindlewood.
- **2.3** How long do you retain personal data, and how can a data subject request access or dele... (Privacy). high risk. Owner: Data Protection Lead, Brindlewood.
- **3.1** Do you hold ISO 27001 certification or a SOC 2 Type II report? Attach the current certi... (Security). high risk; Not supported: no current evidence; clarification: Please confirm if the company holds ISO 27001 or SOC 2 Type II certification and provide the relevant certificate or report if available. Owner: CTO, Brindlewood.
- **3.2** Do you encrypt customer data at rest and in transit? State the algorithms and key manag... (Security). high risk. Owner: CTO, Brindlewood.
- **3.3** Do credentials, API keys or passwords belonging to our users pass through or get stored... (Security). high risk. Owner: CTO, Brindlewood.
- **3.4** Describe your incident response process and your breach notification timeline to custom... (Security). high risk; Not supported: no current evidence; clarification: Please provide the documented incident response process and the specific timeline (e.g., hours or days) for breach notification to customers. Owner: CTO, Brindlewood.
- **4.2** What is your uptime SLA, your standard limitation of liability, and do you carry cyber... (Commercial). high risk; Partly supported; clarification: Please confirm the standard limitation of liability clause and provide evidence of cyber liability insurance coverage. Owner: Head of Operations, Brindlewood.
## What the user should do next
- Send these items to their owners for review: Data Protection Lead, Brindlewood: 2.1, 2.2, 2.3; CTO, Brindlewood: 3.1, 3.2, 3.3, 3.4; Head of Operations, Brindlewood: 4.2.
- Check every draft against its cited source and approve it before submission. Nothing has been sent or submitted.