No certifications claimed
It lists no SOC 2, ISO 27001, GDPR or other certificates, report numbers or auditors, and doesn’t claim any are in progress.
SECURITY & DATA · EVALUATION GUIDE
Security reviews start with the right questions
A checklist for procurement, security and legal teams evaluating a SaaS product: what to ask for, and what evidence should back each answer.
What this page is
No invented tests
It doesn’t claim penetration tests, bug bounties, red-team exercises or third-party assessments.
No service levels
It promises no SLA, availability, response time, hosting region or data residency.
No customer data
It contains no real customer names, volumes, usage figures, screenshots or log samples.
Placeholders are marked
Every email address, timeframe and field name here is a placeholder and marked as one.
Contracts take precedence
For a real purchase, the signed contract, data processing agreement (DPA) and formal security documents always take precedence.
Summary and how to use it
Who it is for
Procurement, legal, IT and security teams can use it to scope their questions. It doesn’t replace formal due diligence.
How to use it
Ask for verifiable written evidence for each section below. Marketing copy is not a certification.
Next step
To see how the product works, take the read-only product tour.
Evidence
There are no downloadable audit reports, penetration test reports, certificates or logs here.
Data model and tenant isolation
The tenant is the smallest boundary
Every record should carry a tenant identifier that is checked on every read, not only filtered in list queries.
Authorization happens on the server
Tenant or role parameters from the browser should never be trusted; the server resolves permissions from the session again.
Cross-tenant access is denied by default
Internal tools, background jobs and support staff go through the same authorization path as users, and leave an audit record.
Delete and export by tenant
A tenant can be exported and deleted completely, with the storage locations, replicas and final cleanup times stated.
Ask the vendor
Is isolation enforced in the application, the database or both? Is there an architecture note or isolation test? How is bypass prevented on shared infrastructure?
Admin self-checks
Admins can see cross-tenant access and support-staff activity that concerns them, for internal audit.
Encryption: how it should be described
How to read this section
It describes what a product should do and what evidence to ask for. Until that evidence exists, treat nothing here as implemented.
In transit
TLS for all public traffic, old protocol versions and weak ciphers disabled, certificate issuance and renewal explained. Ask for: TLS configuration and a scan result.
At rest
Encrypted volumes and databases, with key management (customer-managed or cloud KMS), rotation and destruction described. Ask for: encryption architecture and key lifecycle documents.
Backups and exports
Whether backups, exports and logs are encrypted too, and whether keys are stored apart from data. Ask for: backup encryption and restore approval process.
Field-level encryption
If certain fields are encrypted again, which ones, who holds the keys and how they are recovered. Ask for: the field list and key custody.
One rule for all of the above
Each point needs verifiable evidence in the vendor’s formal security documents.
Identity and access: who is responsible
The platform
Provides sign-in methods, the role model, maximum session length and global revocation; owns platform security updates, key rotation and incident notices.
Team admins
Assign roles, turn on or require multi-factor authentication, set session and network policies, remove leavers and transfer what they own.
Members
Keep credentials and MFA devices safe, never use shared accounts, report unusual sign-ins promptly.
Least privilege
Minimum necessary permissions by default; export, delete, permission changes and key management are authorized and logged separately.
Sessions
Session expiry, sign out of all devices, concurrent session view and unusual sign-in alerts. Exact limits belong in the formal documents.
Multi-factor authentication
One-time codes or security keys; whether it can be required per team should be confirmed in the product and its documents.
Audit events and retention
Example event types
Invitations and role changes, MFA changes, successful and failed sign-ins, session revocation, export and deletion requests, permission policy changes, support-staff access with ticket number.
Example fields
Time (UTC), event type, actor, target, result, source IP, client, tenant ID, related request ID.
How retention should be stated
With a concrete number and its basis (for example 90 days or 12 months), whether it is configurable, whether expired logs are deleted or archived, and whether there is an export or audit API.
Ask the vendor
Does retention vary by plan? CSV or JSON export? Can admins see their own audit records? Are logs stored apart from tenant data?
Samples
This page contains no real audit records, log screenshots or user identifiers.
Export, deletion, backup and recovery
Export
Export by tenant in an open format, stating the scope (attachments, metadata), file encryption, link expiry and access audit. Ask for: the data processing description.
Deletion
Member, object and tenant deletion; soft or hard delete; the recovery window; how backup copies are handled and the final cleanup time. Ask for: the deletion process and a sample certificate.
Backup
Frequency, copies kept, cross-zone or cross-region, backup encryption and restore approval. Ask for: the backup policy.
Recovery
Recovery granularity (whole tenant or single object), recovery time and point objectives, who starts and approves it, how often it is rehearsed and the latest result.
Put it in the contract
Write the timeframes and scope you need into the contract or DPA rather than relying on web pages or verbal promises.
Sub-processor list: the fields to expect
Field: name
The legal name and role of each sub-processor. Placeholder: [Sub-processor A].
Field: purpose
Why data is processed, for example hosting, email, error monitoring or payments. Placeholder: [purpose].
Field: data categories
Which data is involved, for example account details, usage logs or billing. Placeholder: [data category].
Field: region
Where data is stored and processed. Placeholder: [to be confirmed in formal documents].
Field: change notice
How you are told about new or replaced sub-processors and how long you have to object. Placeholder: [notice window].
Field: contractual terms
The data protection terms signed with each sub-processor. Placeholder: [terms].
Incident response and customer notice
1. Detect and classify
Establish the impact (customer data? more than one tenant?), assign a severity and record the time.
2. Contain and fix
Isolate affected systems, rotate keys and credentials, close the entry point and keep forensic evidence.
3. Notify internally
Notify the security lead and legal by severity; start customer communication when customer data is involved.
4. Notify customers
Within [XX] hours of confirmation, tell affected team admins the known facts, impact, actions taken and next steps. The timeframe is a placeholder to be set in the contract.
5. Update and review
Regular updates, root cause, fixes and prevention, and an incident report as the contract requires.
What binds
Only terms written into the contract or DPA are binding.
Responsible disclosure
Where to report
security@example.com (placeholder). A real product publishes a verified security contact and a response commitment.
Encrypted contact
Placeholder: no public key yet. A real product publishes a key fingerprint and an encrypted channel.
What to commit to
How quickly reports are acknowledged, how vulnerabilities are handled and how disclosure is coordinated. No bug bounty should be claimed unless one exists with published scope and rules.
How to report
Include steps to reproduce, the impact and what you expect, without real customer data or production credentials.
Limits
No bug bounty, cash reward, confidentiality waiver or acknowledgement deadline is offered here.
Shared responsibility
The provider
Application and infrastructure security updates, tenant isolation, audit and backup infrastructure, platform incident response, and the compliance and security documents.
Team admins
Members and roles, MFA policy, offboarding, export and deletion approval, regular audit log review, integrations and API tokens.
Members
Account and device security, least privilege, no data beyond what is authorized, reporting anything unusual to their admin.
Agreed by both
Processing scope, retention, sub-processors, notice periods and regional limits belong in the contract or DPA.
Procurement and security checklist (copy these questions)
1. Certifications and reports
Which certifications or audit reports are current, their scope, the period covered and how to obtain them under NDA.
2. Penetration testing
When the last third-party or internal test took place, its scope, the number of findings and their status.
3. Encryption
How data is encrypted in transit and at rest, who manages the keys and how often they rotate.
4. Tenant isolation
Where isolation is enforced, cross-tenant access control and how internal access is approved.
5. Authentication
Supported MFA methods, whether it can be required, maximum session length and global revocation.
6. Permissions
The role model, least-privilege defaults and extra authorization for sensitive actions.
7. Audit logs
Event types, fields, retention, export format and what admins can see.
8. Export
Scope, format, encryption and link expiry.
9. Deletion
Granularity, recovery window, cleanup of backup copies and deletion certificates.
10. Backup and recovery
Frequency, copies kept, recovery granularity, recovery time and the latest rehearsal.
11. Sub-processors
Completeness of the list, change notices and the objection period.
12. Incident response
Severity levels, notice times, notice content and the form of the review report.
13. Region and residency
Countries or regions where data is stored, transfer routes and cross-border mechanisms.
14. Contracts
DPA, standard contractual clauses, insurance and liability caps.
Using this checklist
Compare the vendor’s written answers with the contract, point by point. Marketing pages and self-assessments don’t replace written evidence.
Questions
Will my data be used to train models?
A product should state whether data is used for training, whether you can opt out and whether it improves general models, and put that in the DPA. Ask for it in writing.
What happens to a leaver’s data and access?
Their account is disabled at once, all sessions and API tokens are revoked, and their data and resources are transferred or deleted. Team admins do it; the platform provides bulk revocation and an audit record.
How safe are public share links?
Ask whether links can expire or carry a password, can be revoked at any time, record who opened them and when, and are hidden from search engines.
Can I export all my data?
A product should export a tenant in an open format and state the scope, encryption and link expiry.
How long does deletion take?
Object and tenant deletion times, backup cleanup and a deletion certificate should be stated. Put the times in the contract.
Where is data stored?
A product should list its regions, cross-border transfer mechanisms and any residency options, and put them in the DPA.
How long are audit logs kept?
The formal security documents should give a number, the configurable range and how expired logs are cleaned up.
Where do I get the DPA and security documents?
A product should provide a DPA template, the sub-processor list, a security whitepaper and a way to answer security questionnaires.
Using this list well
Bring these questions into a real procurement and ask real vendors for written evidence.