The short version
Nobody can create their own account. Access is granted by an administrator at your organization and withdrawn the same way.
The information a user enters while working stays on their device. It is not uploaded to us, so there is no central store of it to breach, subpoena, or lose.
The only personal data we hold on a server is the email address that serves as a username, plus the credentials needed to verify it.
Who can get in
Access is closed by default, and closed at more than one layer so that a single misconfiguration does not open it:
- No self-registration. There is no sign-up page and no way to create an account from the app. Registration is refused at the service itself, not merely hidden in the interface.
- Administrator-created accounts only. An account exists because a named administrator at a licensed organization created it for a specific colleague.
- Organization domain restriction. Accounts can only be created for email addresses at domains an organization has approved. The domain is matched as a whole, not as a fragment of a longer name, so lookalike domains are refused.
- Administrator-controlled recovery. There is no self-service password reset. Resets are performed by an administrator, which means access cannot be recovered by someone who has compromised only a mailbox.
- Immediate revocation. Removing an account ends access. There is no secondary path back in.
How people prove who they are
Passwords are never stored in a readable form. Users may additionally enable a passkey, which lets the device itself confirm the user's identity using the biometric or passcode protection already on that device.
With a passkey, the secret that authenticates the user never leaves their device and is never transmitted or held by us. There is nothing on a server that could be stolen and replayed, and nothing a user can be persuaded to read out over the phone.
Where information actually lives
This is the part most security reviews care about, so it is worth being precise.
- Operational information stays on the device. What a user enters while working through a task is held in memory while they work and discarded when they finish. It is not written to our servers.
- Messages are sent by the user, not by us. When the app prepares a message, it hands the draft to the user's own email application. The user decides whether to send it, and it then travels through their organization's mail system. We never hold a copy.
- Account records are minimal. An email address, credential material, and sign-in records. No names, badge or payroll numbers, photographs, phone numbers, or location data.
The practical consequence: an organization's operational information does not accumulate in our systems, because it never arrives there.
Protecting information
- All traffic between the app and our services is encrypted in transit using current TLS.
- Data at rest in our infrastructure is encrypted.
- Administrative access to our cloud environment is restricted, requires multi-factor authentication, and is logged.
- Infrastructure is defined as code and changed through a reviewed process, so a configuration change is a deliberate, recorded act.
Monitoring and records
Sign-in attempts and administrative activity are logged so that suspected misuse can be investigated after the fact. Security-relevant records are retained for up to twelve months and then deleted. If we become aware of a breach affecting an organization's account data, we will notify that organization promptly.
What the app is built from
The application ships with no third-party libraries, no advertising or analytics software, and no tracking of any kind. Every line that runs on the device is ours or the platform's.
This is a deliberate security decision as much as a privacy one. Third-party code is the most common way an application acquires a vulnerability it did not write, and a supply chain it cannot audit. There is no such supply chain here.
What we do not claim
DEVI holds no CJIS, HIPAA, FedRAMP, SOC 2, or equivalent certification, and we will not tell you otherwise. If a vendor tells you their app is "CJIS compliant", ask to see the audit.
What we can tell you is exactly what the software does and does not do, which is the basis on which your own security team should assess it. We will answer specific questions from an organization's IT or security staff directly, in writing, including questions this page does not cover.
Your organization remains responsible for classifying its own information, for its records retention, and for any message a user chooses to send from their own account.
Reporting a vulnerability
If you believe you have found a security vulnerability, email contact@deviops.app with enough detail to reproduce it. Please report it to us before disclosing it publicly.
In return, we commit to:
- Acknowledge your report within three business days.
- Tell you our assessment, and whether we are treating it as a vulnerability, within ten business days.
- Keep you informed while we fix it, and confirm when the fix ships.
- Credit you if you would like to be credited.
- Not pursue or support legal action against anyone acting in good faith under this policy.
Please do not access, modify, or retain information belonging to anyone else, degrade the Service for others, or use social engineering against our staff or our customers' staff.
For IT and security teams
If you are evaluating DEVI for an organization and need detail this page does not cover — architecture, data flow, subprocessors, incident response, or a security questionnaire — write to contact@deviops.app and say which organization you represent. We will answer directly.