Security at Noevika

Noevika monitors public breach data for you; it should never become a source of exposure itself. This page is written for the person filling in a vendor-security questionnaire: what we hold, how it is protected, who we rely on, and how to reach us. Last reviewed 2026-11-07.

Subprocessors

Infrastructure providers acting on our instructions. We will update this list and note the date when it changes.

Questionnaire answers

The questions we are asked most, answered as we would in your form. Copy freely; ask for anything missing.

Do you store passwords?

No. Sign-in is a one-time 6-digit code emailed to the address (10-minute expiry, 5 attempts, rate-limited) or Google / Microsoft OpenID Connect. There is no password to breach or reuse.

What personal data do you hold?

Email address, optional first/last name, preferences, consent records (version, timestamp, IP, user-agent), delivery metadata (bounces, complaints), and the vendors / organisations / keywords a user or team chooses to watch. For teams: team name, optional logo, member roles, an audit log of team actions keyed by account id. Nothing about your own security posture is collected.

How is it protected at rest?

Names and emails are encrypted with AES-256-GCM before they reach the database; keys live in SSM Parameter Store (SecureString, KMS-backed), separate from the data. Email lookups use a keyed hash, not the plaintext address. API keys are stored as SHA-256 hashes and shown once. Slack/Teams webhook URLs and invitation tokens are encrypted or hashed. DynamoDB encryption at rest and point-in-time recovery are enabled.

And in transit?

TLS 1.2+ everywhere: browser → Cloudflare → API Gateway → Lambda. The session cookie is HttpOnly, Secure, SameSite=Lax. Public read endpoints are served without credentials; account endpoints never accept a wildcard origin.

Who can access production?

One operator. Deploys run from GitHub Actions through short-lived OIDC credentials — no static AWS keys exist. Admin pages require an admin role on the account, an 8-hour session, and a fresh sign-in within the last hour (step-up) for any action that reveals personal data; every such action is written to an audit log with the reason given.

Is data isolated between customers?

Yes. Every team route acts only on the signed-in user's own team — a team id never appears in a URL, so another team cannot be addressed by guessing. Roles (owner / admin / member) gate settings, invitations and member changes. Invitations are random tokens stored hashed, expire in 7 days, are single use, and can only be accepted by the account for the exact address they were sent to.

Where does the incident data come from, and do you store leaked data?

Public sources only: CISA KEV and advisories, HHS OCR, state attorneys general, SEC EDGAR 8-K Item 1.05, ransomware-claim trackers and named security-news outlets. Every item links to its original publisher. We never store or reproduce content from leak sites, and ransomware claims are labelled as claims.

Retention and deletion?

Account data is kept while the account exists and deleted entirely (including consent logs) within 24 hours of the user deleting it from Preferences. Unverified sign-ups expire after 7 days. Team audit logs are kept one year; admin audit logs one year; exposure-check leads 400 days. Verification codes expire in 10 minutes. Users can also unsubscribe with one click (RFC 8058) from any email.

Subprocessors?

Listed on this page. We do not sell or share personal data, and we do not use third-party analytics or advertising trackers on the site.

Backups and availability?

DynamoDB point-in-time recovery (35 days). Static site on Cloudflare's edge; API on AWS Lambda behind API Gateway (multi-AZ by design). CloudWatch alarms on ingest failures and API errors page the operator. No formal SLA on the free plan; an SLA is available on Enterprise terms.

Vulnerability management?

Dependabot on every dependency; CI blocks merges on failing tests and lint; Python dependencies are audited with pip-audit and the web app with npm audit. Report a vulnerability to security@noevika.com — we acknowledge within 2 business days and credit researchers who wish to be named.

Incident response?

If we become aware of a breach affecting your personal data we will notify affected users by email without undue delay, and within 72 hours where GDPR applies, with what happened, what data was involved and what we did. Contact for anything urgent: security@noevika.com.

Certifications?

None yet. Noevika is an early-stage product; the code is open source (Apache-2.0) so controls can be inspected directly, and this page plus the DPA answer most questionnaires. SOC 2 Type I is on the roadmap once customer demand justifies the audit cost — ask us where it stands.

Data location and transfer?

All data is stored and processed in the United States (AWS us-west-2). For EU/UK customers the DPA incorporates the EU Standard Contractual Clauses and the UK Addendum.

Do you support SSO and SCIM?

Yes, for teams. Single sign-on is OpenID Connect against your own identity provider (Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin and others): authorization-code flow with PKCE and nonce, ID tokens verified against your IdP's published keys, and only addresses on domains you have verified by DNS are admitted. By default Noevika is registered in your IdP as a public client, so no client secret is shared at all; a confidential client (secret scoped to the Noevika app registration, revocable in your IdP, stored encrypted here) is optional for IdPs whose policy requires one. SSO can be made mandatory for members, with the team owner keeping email-code sign-in as break-glass. Provisioning is SCIM 2.0 (Users; create, deactivate, delete) with a per-team bearer token stored hashed. We do not currently offer SAML; if your procurement requires it, write to hello@noevika.com. The five sign-in approaches, what each shares, the standards behind them and per-IdP setup are on /docs/sso/.

What do your integrations send, and do you hold credentials to our systems?

Issue trackers (Jira, ServiceNow, others) are reached through an incoming webhook you create in your own tool — we hold the URL and, optionally, one request header you choose, stored encrypted; never an account token for your system (an API-token mode exists for Jira sites without Automation and is marked advanced). Payloads contain public incident data and, only if you choose the full level, the vendor name and tier your team assigned; a minimal level omits those and a ping level sends ids only so your receiver pulls details with its own API key. Deliveries are signed (HMAC-SHA256 with timestamp and delivery id), go only to public HTTPS hosts, are re-validated on every send, never follow redirects, and are retried at most three times. SIEM destinations (Splunk HEC, Microsoft Sentinel via the Logs Ingestion API) and PagerDuty receive the same event with the same payload levels; the HEC token, Entra client secret and PagerDuty key are stored encrypted, never returned, and only ever used to push — nothing is read from your systems. Our outbound guard resolves DNS from our side, so an internal-only hostname is refused by design: put a relay or a public ingest endpoint in front of internal systems.

Does the AI feature send my data to a model provider?

AI briefs are generated only from the public incident sources, inside our AWS account via Amazon Bedrock. No customer or personal data is included in prompts, and nothing is used for model training.