A security company has to be safe to let in the building.
Everything below is a commitment, not a marketing promise. If any part of it does not fit your governance, tell us before the sprint and we will adjust the scope in writing.
How we work with your systems and your data.
Written authorization for every technical check
Privacy notice and data-processing terms where applicable
NDA available and agreed before evidence exchange where required
Clear report disclaimer: readiness, not certification
Defined data retention and deletion policy
Incident contact process for Cybnivo itself
Separate terms for free pilots and paid pilots
Professional liability / cyber-insurance discussion before larger engagements
- A fixed, fast readiness sprint for SMEs
- A translation layer between security detail and management decisions
- A reviewed, AI-assisted reporting workflow
- A pre-purchase roadmap before you buy more tools
- Able to add safe industrial readiness
- Another NIS2 compliance platform
- A certification or audit body
- An OT penetration-testing company
- A replacement for Microsoft, auditors, MSPs or MDR providers
- A fear-based security marketing shop
Cybnivo does not issue certifications and never states or implies that a company is certified, compliant or audited as a result of the sprint.
How this website and its data are protected.
We hold our own platform to the standard we assess our clients against. The application implements the controls below; infrastructure and provider controls are verified as part of our production configuration.
Transport & browser hardening
HTTPS with HSTS, a Content-Security-Policy, clickjacking protection (frame-ancestors none), MIME-sniffing protection and a locked-down Permissions-Policy on every response.
Isolation
Cross-origin opener and resource policies isolate the site from other browsing contexts, and server implementation headers are stripped from responses.
Input validation, twice
Every public form is validated in the browser and again in the database with constraints on format, length and content — so a crafted request that bypasses the interface is still rejected.
Injection resistance
All database access goes through parameterised queries, and script/HTML payloads are rejected at both layers. React escapes all rendered output by default.
Abuse and flood protection
Public forms are submitted through our own server, never straight from the browser to the database. Submissions are re-validated, re-scored server-side and rate limited per visitor and site-wide, alongside per-address limits in the database and client-side throttling. Additional abuse controls are added as the service moves further into production.
Least-privilege data access
Row-Level Security is enabled on every table. The public can submit but never read. Privileged roles are stored separately from user profiles and checked by a security-definer function in a private schema, which significantly reduces privilege-escalation risk.
Encryption at rest and in transit
TLS is enforced on every connection between the site, the database and your browser, and data is held on managed infrastructure with encryption at rest. Details of hosting region, backup handling and retention are confirmed in writing before any engagement.
Dependency and configuration monitoring
We review dependencies for known vulnerabilities and scan the backend configuration for missing access rules as part of our release routine, and we act on what those checks report.
Coordinated disclosure
A published security.txt gives researchers a direct, documented way to report an issue to us.
Found a security issue? Report it to info@cybnivo.com — see /.well-known/security.txt. We acknowledge reports within two business days.
Ask us anything before you share a single log.
Send data-protection questions directly to info@cybnivo.com and we will answer in writing before the engagement starts.
Review our handling before you scope the work.
We are happy to complete your vendor questionnaire as part of the discovery call.
Permission-based · Reviewed before delivery