Trust Center

Security, privacy, and compliance — written for vendor reviewers.

Last updated August 30, 2026

This page is written for security, legal, and IT reviewers evaluating LazySEM as a vendor. It answers the questions that appear on a standard vendor security questionnaire, in the order they are usually asked.

LazySEM is a small company. We do not hold a security certification, and we would rather say so plainly and show you our actual controls than leave the question unanswered. Where a control is not in place yet, this page says that too. Everything below is a description of what is running today, not what we intend to build.

For the binding versions of anything summarised here, see the Terms of Service at /terms, the Privacy Policy at /privacy-policy, and the Data Processing Addendum at /dpa.

Quick answers

QuestionAnswer
Do you hold ISO 27001, SOC 2, or another security certification?No. We hold no security certification and have no audit currently scheduled. See Certifications and independent assurance below.
Where is customer data stored?In the European Union. Application services, the PostgreSQL database, and the cache run in Railway's EU West region.
Who are your hosting providers?Railway for application services, database, and cache. Netlify for the marketing website and CDN. The full provider list is at /subprocessors.
Is data encrypted in transit?Yes. HTTPS with TLS for all public traffic, with HTTP redirected to HTTPS, and HSTS on lazysem.com and app.lazysem.com.
Is data encrypted at rest?Yes, through our managed infrastructure providers. Connected integration tokens, such as Google OAuth tokens, are additionally encrypted by LazySEM before storage. We do not manage our own database encryption keys.
Do you have an incident response process, and what is your breach notification timeline?Yes. We notify affected customers without undue delay and in any event within 72 hours of becoming aware of a personal data breach affecting their data. This is a contractual commitment in section 11 of our DPA, not a best-effort statement.
What internal access controls are in place?Access to production infrastructure is limited to authorised operators who need it to run or support the service. Inside the product, every organisation has role-based access control with four roles and a per-organisation audit log.
Do you conduct third-party penetration testing?No independent penetration test has been performed to date. This is an open gap and it is on our roadmap.
Do you support multi-factor authentication?Yes. Time-based one-time passwords (TOTP) from any standard authenticator app, with ten single-use backup codes. Users turn it on under Settings, then Security. Organisation-wide enforcement is not available yet, so today MFA is per-user and opt-in.
Do you support SSO or SAML?No. There is no SAML or SCIM support today.
Is a Data Processing Agreement available?Yes, at /dpa. It is binding through section 13 of the Terms and needs no separate signature.
Is there an API?Yes. Personal access tokens and a Model Context Protocol endpoint for connecting external AI clients.
Do you publish an uptime SLA?No. We do not publish an uptime commitment today. See Availability below for why.
Do you use subprocessors?Yes. Ten providers, listed with entity and country at /subprocessors, with 30 days' advance notice before any addition.
What happens to my data after termination?At your choice, we return it in a machine-readable format or delete it. If no choice is made within 30 days, we delete it.
Can a user delete their own account?Yes, from Settings, then Security. The account locks immediately and the data is removed after a 30-day grace period. Users can also download their account data from the same page.
Where do I report a security vulnerability?info@lazysem.com. See Vulnerability disclosure below.

Who you are contracting with

LazySEM is operated by Got Reach s.r.o., a company registered in the Czech Republic, company registration number (ICO) 23712082, VAT number CZ23712082, registered office Zlochova 2405/8, Modrany, 143 00 Praha, Czech Republic.

Got Reach s.r.o. is established in the European Union, so it is directly subject to the GDPR and does not require an Article 27 representative. Its lead supervisory authority is the Czech Office for Personal Data Protection.

Czech law governs the Terms of Service, and Czech courts have jurisdiction.

Where your data is stored

Customer application data is stored in a managed PostgreSQL database running in Railway's EU West region, along with the application services and the Valkey cache that support them.

The marketing website is served from Netlify's global edge network. That network serves public pages only and holds no customer application data.

Some subprocessors are established outside the European Economic Area. For those transfers we rely, as applicable to each recipient, on an adequacy decision of the European Commission or on the European Commission's Standard Contractual Clauses (Decision 2021/914) as incorporated into that provider's data processing agreement. For customers subject to UK data protection law, the UK International Data Transfer Addendum applies. A copy of the safeguards relied on for any specific provider is available on request.

Encryption

In transit, LazySEM uses HTTPS with TLS for all public traffic. Plain HTTP requests are redirected to HTTPS. HTTP Strict Transport Security is set on the hosts people browse, lazysem.com and app.lazysem.com.

At rest, LazySEM relies on encryption provided by its managed infrastructure providers for database and cache storage. LazySEM does not operate its own key management system and does not hold its own database encryption keys.

Above that provider-level encryption, LazySEM applies application-level encryption to sensitive integration tokens, such as the Google OAuth tokens created when a user connects Google Analytics or Search Console. Those are encrypted by LazySEM before they are written to the database.

Passwords are never stored. They are hashed with bcrypt using a per-password salt, and only the hash is retained.

Access control

Internally, access to production infrastructure and customer data is restricted to authorised operators who require it to operate, maintain, or support the service. LazySEM does not provide unrestricted third-party access to production systems, including during customer audits, because doing so would expose other customers' data.

Inside the product, each organisation is a separate tenant with role-based access control. There are four roles:

  • Owner, which holds full control of the organisation including billing and deletion
  • Admin, which can manage members, invitations, and organisation settings
  • Member, which can use the product's features
  • Viewer, which is read-only

Permissions are enforced server-side against the caller's role on every administrative action, including organisation updates, invitations, member role changes, member removal, and token creation. The role held in the browser cannot be used to grant access the server has not authorised.

Every organisation has an activity log recording authentication events, administrative actions, and membership changes. Organisation administrators can view it in the product and export it as CSV.

Authentication

Accounts are created with an email address and a password, or through Google sign-in. Email addresses are verified.

Password handling includes bcrypt hashing, a password reset flow with expiring single-use tokens, and rate limiting on authentication endpoints. Access tokens can be revoked server-side through a token denylist, so a logout or a revocation takes effect immediately rather than waiting for token expiry.

Multi-factor authentication is available. LazySEM supports time-based one-time passwords (TOTP) from any standard authenticator application, such as Google Authenticator, 1Password, or Authy. No SMS or email codes are involved, so there is nothing to intercept in transit and nothing to deliver.

Enrolment is deliberately two-step. You scan a QR code, or type the setup key if you cannot scan, and then confirm with a code your app generates. Only that confirmation switches MFA on, so a scan that silently failed cannot lock you out of your own account.

Ten single-use backup codes are issued at enrolment and displayed once. Only their hashes are stored, so we cannot show them to you again and we cannot use them on your behalf. You can generate a fresh set at any time, which invalidates the previous one.

Turning MFA off requires both your password and a current code, and clears the stored secret rather than only the setting.

If you lose your authenticator and your backup codes, an owner or administrator of your organisation can reset your enrolment from the Team Members page, and you set it up again. That reset is written to the organisation's audit log. It cannot be used on your own account, so a stolen session cannot be used to switch the second factor off, and an administrator cannot reset an owner's. At no point can an administrator read your secret or your backup codes, or sign in as you.

Organisation-wide enforcement, where an administrator requires every member to enrol, is not available yet. Today MFA is per-user and opt-in. That is on the roadmap below.

There is no SAML, OIDC-as-identity-provider, or SCIM support. If enterprise single sign-on is a requirement for your organisation, please tell us, as it affects how we prioritise it.

Application security

The following controls are in place in the production application:

  • Security headers on application and API responses: X-Frame-Options set to DENY, X-Content-Type-Options set to nosniff, and a strict-origin-when-cross-origin referrer policy
  • HTTP Strict Transport Security on lazysem.com and app.lazysem.com
  • A Content Security Policy on the application at app.lazysem.com
  • Cross-site request forgery protection using the double-submit cookie pattern
  • Rate limiting on authentication and API endpoints, backed by a shared cache so limits hold across service instances
  • Request size limits to constrain oversized payloads
  • Security event logging on authentication and administrative actions
  • Service-to-service calls authenticated between internal services rather than trusted by network position alone

Payments

Payments are processed by Stripe. Card details are entered directly with Stripe and are not stored by LazySEM. Stripe is PCI-DSS certified. LazySEM stores only subscription and invoice metadata needed to operate billing.

Backups and availability

The PostgreSQL database is backed up automatically by our managed database provider, and backups inherit that provider's encryption. Restoring from backup is a documented operational task, but we have not yet completed a formal, timed restore drill, so we do not publish a recovery time or recovery point objective. Completing that drill is on the roadmap below.

We do not publish an uptime SLA. We would rather publish none than publish a number our current architecture cannot honour: services run as single instances today, so deploys and restarts cause brief interruptions. Multi-instance deployment comes before any uptime commitment. We use commercially reasonable efforts to keep the service available, as set out in section 15 of the Terms.

There is no public status page yet. Service disruptions are communicated by email to affected customers.

Incident response and breach notification

LazySEM investigates and responds to suspected security issues affecting the service. Where an incident is confirmed to affect customer data, we take reasonable steps to investigate, contain, and remediate it.

If a personal data breach affects a customer's data, we notify that customer without undue delay and in any event within 72 hours of becoming aware of it. Notification is not held back until the investigation is complete: an initial notification goes out on awareness and is updated as more becomes known. The notification describes, to the extent known, the nature of the breach, the categories and approximate volume of data and data subjects affected, the likely consequences, and the measures taken or proposed.

We also assist customers with their own obligations under Articles 33 and 34 of the GDPR. These commitments are contractual, in section 11 of the DPA at /dpa.

Data protection and your rights

The Data Processing Addendum at /dpa is a binding Article 28 processing agreement, incorporated into the Terms of Service. It does not require a separate signature, though we are happy to execute a counterpart on request.

It covers the roles of the parties, the categories of data and data subjects, our processing instructions, subprocessor authorisation and flow-down, international transfer safeguards, security measures, confidentiality, breach notification, assistance with data subject requests, return and deletion, and audit cooperation.

On data subject requests, we assist whether or not the relevant capability is exposed as a self-service feature in the product, and we respond in time for you to meet your own statutory deadline.

Two of those rights are self-service. Under Settings, then Security, a user can download their account data, and can delete their own account. Deleting locks the account immediately and removes the data after a 30-day grace period, during which the request can still be cancelled by contacting us. If the person deleting is the only owner of an organisation that still has other members, the request is refused and names that organisation, so colleagues are not left without anyone able to manage billing or membership.

On termination, we return your personal data in a commonly used machine-readable format or delete it, at your choice. If no choice is expressed within 30 days of termination, we delete it. Records we must keep for legal, tax, or accounting reasons remain protected by the DPA for as long as we hold them.

We maintain Records of Processing Activities under Article 30, a documented personal data breach procedure and register, and a data protection impact assessment covering our processing of public forum and user-generated content. These are internal accountability documents, available to customers on request under section 14 of the DPA.

Retention schedules are defined per data category, so that data is not held indefinitely by default.

Subprocessors

We publish our full subprocessor list at /subprocessors, naming each provider, the service it performs, and its legal entity and country.

Before a new subprocessor begins processing customer personal data, we update that page and notify the account's administrative contact by email at least 30 days in advance. Customers may object on reasonable data protection grounds, as set out in section 7 of the DPA.

To be added to the subprocessor change notification list, email info@lazysem.com with the subject "subprocessor updates".

Certifications and independent assurance

LazySEM does not hold SOC 2, ISO 27001, or any other security certification, and no audit is currently scheduled. No independent penetration test has been performed to date.

We would rather state that plainly than imply an audit is imminent. A certification programme is a significant, multi-year commitment, and we are not going to publish a target date we are not funding.

What we offer instead:

  • This page, which describes the controls actually running rather than the ones an audit would require
  • A completed security questionnaire, published in full at /security-questionnaire rather than sent on request, covering the same ground as a CAIQ or SIG Lite
  • Evidence behind any individual control listed on this page, on request
  • Contractual audit cooperation under section 14 of the DPA, including responses to your own security questionnaire, on reasonable written request

If a certification is a hard requirement for your procurement process, tell us. It changes how we prioritise, and we would rather know than be quietly declined.

Vulnerability disclosure

If you believe you have found a security vulnerability in LazySEM, please report it to info@lazysem.com with "security" in the subject line. Please include enough detail to reproduce the issue.

We will acknowledge your report within 5 business days and keep you informed as we investigate.

We ask that you give us a reasonable opportunity to remediate before public disclosure, that you do not access, modify, or delete data belonging to other users, that you do not degrade the service for others through automated scanning or denial-of-service testing, and that you do not use social engineering against our staff or customers.

If you report in good faith and follow the guidance above, we will not pursue legal action against you for your research.

We do not currently operate a paid bug bounty. Reports are reviewed and fixed on their merits, and we will credit reporters who want to be credited.

What we are working on

We publish this so you can see the gaps we already know about rather than discovering them yourself:

  • Organisation-wide MFA enforcement, so an administrator can require every member to enrol
  • A first independent penetration test
  • A formal, timed backup restore drill with published recovery objectives
  • Multi-instance deployment, followed by a published uptime SLA
  • A public status page
  • A dedicated security contact address, replacing the shared inbox above

Contact

For security questions, questionnaires, DPA requests, or evidence requests, contact info@lazysem.com. For privacy and data protection matters, including data subject requests, use the same address.