Security at nrtur

nrtur is a small team building an early-access product. That shapes what we can honestly claim. Rather than describe an aspirational security programme in the present tense, here is the real status of each control.

This website runs on Vercel. The nrtur application runs on established cloud infrastructure in the United States, and we do not operate our own hardware — meaning physical security, network isolation, and hypervisor patching are handled by providers who do that at a scale we never could.

The full list of vendors that can touch your data, what each one does, and where it sits, is published in the sub-processor table in our privacy policy. We update it before a new vendor starts processing anything.

• In transit — TLS on every connection, to the website and the application alike. HTTP requests are redirected, not served.
• At rest — application data and backups are encrypted on disk by the storage layer.
• Passwords — stored as slow, salted hashes, never as reversible ciphertext and never in plain text. We cannot recover your password, only help you reset it, and we will never ask you for it.
• Secrets — API keys and credentials live in managed environment configuration, not in the codebase or in version control.

Our staff

Production access is limited to the engineers who need it to run the service. It requires multi-factor authentication, it is logged, and it is used for exactly three things: keeping the service running, fixing a fault, and complying with a valid legal order.

We do not read your CRM records out of curiosity, and we do not use them to market to your contacts. When we need to look at a specific record to debug something you reported, we look at that record.

Your team

Inside your workspace, the account owner controls who has a seat and what they can reach. Removing someone removes their access immediately. Role-based permissions, SSO/SAML, and audit logs are part of the Business plan at launch.

Isolation between customers

nrtur is a multi-tenant service. Every record is bound to a workspace, and queries are scoped to the authenticated workspace so one customer cannot read another's data. This is enforced in the data layer rather than left to individual screens to remember.

• Backups run automatically, are encrypted, and are stored separately from the primary database.
• We periodically restore from backup and check the result, because a backup nobody has restored is not a backup.
• Deleted data rolls out of backups within 90 days — the same window described under retention.

We do not currently publish a contractual RTO or RPO. When we commit to one, it will appear in the Terms of Service rather than as a number on a marketing page.

• Code review — changes are reviewed before they reach production.
• Dependencies — we get automated alerts for known vulnerabilities in the packages we use, and patch on a risk basis, fastest for anything reachable from the internet.
• Least privilege by default — new services get the narrowest access that works, not the broadest that is convenient.
• No production data in development — we do not copy customer records into test environments.

No system is perfectly secure and we will not pretend otherwise. What we can commit to is how we behave when it matters.

1. Contain — cut off the access path and stop the bleeding first.
2. Assess — establish what was reached, by whom, and for how long.
3. Notify — where a breach affects personal data we notify the relevant regulator and affected customers without undue delay, and within 72 hours of becoming aware where GDPR applies.
4. Explain — you get the facts we have, including the uncomfortable ones, not a statement engineered to sound reassuring.
5. Fix — we close the hole and tell you what changed so it does not recur.

Please tell us before you tell anyone else. Email ops@nrtur.io with the subject line "Security" and include enough detail to reproduce it — a proof of concept, the affected URL or endpoint, and what an attacker could achieve.

What we commit to

• We acknowledge reports within two business days.
• We tell you our assessment and an expected fix window within ten business days.
• We credit you publicly when the fix ships, if you would like to be credited.

Please do not

• Run automated scanners that degrade the service for other customers, or attempt denial of service.
• Access, download, or modify data belonging to another customer. If you can prove the flaw with your own test account, use your own test account.
• Use social engineering, phishing, or physical attacks against our team or our vendors.
• Publish details before we have had a reasonable chance to fix them.

We do not currently run a paid bug bounty. We will say so plainly rather than imply a reward that does not exist.

Most real-world breaches of SaaS accounts are credential problems, not platform problems. The things that actually protect you:

• Use a strong, unique password and a password manager. Reused passwords are the single most common way accounts fall.
• Turn on multi-factor authentication the moment it is available.
• Remove people from the workspace the day they leave, not at the end of the quarter.
• Give teammates the narrowest role that lets them do their job.
• Only put data in nrtur that you have a lawful basis to hold — and keep special-category data out entirely.
• Tell us fast at ops@nrtur.io if you suspect an account has been compromised. Speed matters more than certainty.

• Vulnerability reports and security questions — ops@nrtur.io, subject line "Security"
• Data Processing Agreements and privacy requests — ops@nrtur.io, subject line "GDPR"
• Post — nrtur LLC, Wyoming, USA

If you are evaluating nrtur and need our security posture in writing for a procurement review, ask — we will answer honestly, including the parts where the answer is "not yet".