The first time a real procurement team looks at your product, they do not read your marketing. They open a spreadsheet. It has been used on twenty vendors before yours, and it will be used on twenty after. Each row is a control, each column is a status, and your job is to fill it in without bluffing. I have watched this process from the vendor side, and the single fastest way to lose the deal is to answer a row you cannot actually support. So this post is the checklist itself, written plainly, with an honest column for where wrxstack sits on each line. Some of those answers are yes. Several are no. Both kinds are stated on purpose.
The reason the list is so consistent across companies is that it is not really about features. It is about who is accountable when something goes wrong. Every item exists to answer one of three questions: can the right people get in and the wrong people stay out, can you prove what happened after the fact, and can we get our data back if we leave. Keep those three questions in mind and the whole checklist stops feeling like bureaucracy and starts making sense.
Single sign-on and multi-factor
Single sign-on, usually shortened to SSO, lets a company control access to your product from its own identity system. Instead of your app holding a separate password for every employee, the company's identity provider vouches for who the person is, using SAML or OIDC. When someone joins, they get access through the same front door as everything else. When they leave, disabling one central account cuts off your product too. That last part is the real reason security teams insist on it. A former employee who still has a live login to a work tool is one of the most common and most avoidable risks in the business.
Multi-factor authentication, or MFA, sits next to SSO on the list. It requires a second proof beyond a password, usually a code or a hardware key, so a stolen password alone is not enough to get in. In most enterprise setups, MFA is enforced by the identity provider rather than by each individual app, which means a product that supports SSO inherits the MFA policy the company already runs. Atlas offers SSO over SAML and OIDC, so it plugs into that model. It does not run its own separate MFA scheme, and it does not need to, because the identity provider handles that layer.
Provisioning and access control
Two rows on the checklist trip up smaller vendors more than any others: provisioning and role-based access control. They sound similar and they are not.
Provisioning is about accounts appearing and disappearing automatically. The common standard is SCIM, which lets a company's directory push user records into your product so that hiring, role changes, and departures sync without anyone filing a ticket. SCIM is what large IT teams mean when they say they want "automated deprovisioning." It is genuinely useful at scale, and it is genuinely hard to build well. wrxstack does not offer SCIM. I want that stated without hedging, because a company running thousands of seats needs it, and pretending otherwise would waste their time and mine. I wrote a fuller explanation of what SCIM does and does not do in a separate piece, and the short version is that it solves a problem most small teams do not yet have.
Role-based access control, or RBAC, is about what a person can do once they are in. A named RBAC system gives you predefined roles like admin, editor, and viewer, and lets an administrator assign them cleanly. Atlas takes a different route. Its access model is built around permissions on the underlying work graph, so what you can see and change follows the structure of the work itself rather than a flat list of role names. That is a deliberate design choice I have written about in a post on how task management is really a permissions problem. It is honest to say it is a permissions model, and honest to say it is not a conventional named-role RBAC panel.
Audit logs
An audit log is the record of who did what, and when. Every meaningful action leaves an entry: a login, a permission change, a record edited, a document shared. Security teams want this for two reasons. During an incident, the log is how you reconstruct what happened. During normal operations, the log is how you answer the auditor who asks whether access is actually being reviewed. A product without an audit log is asking a company to trust it blindly, and mature buyers will not.
Atlas keeps an audit log. Because the whole product sits on a single connected work graph, the log is not bolted on after the fact; the same structure that records the work records the changes to it. I go into the reasoning behind that in a post on least privilege in practice, which covers how access and logging reinforce each other. This is one of the rows where wrxstack can honestly write "yes."
Data export and portability
The export row is the one buyers under-rate and I rate highly. It asks a simple question: if we decide to leave, can we take our data with us in a usable form. A vendor that makes export slow, partial, or deliberately painful is holding your data hostage even if it never says so. The strongest signal of a trustworthy vendor is that leaving is easy, because a company confident in its product does not need to trap you. Atlas exposes a public API, which means your data is reachable programmatically rather than locked behind a screen. You can pull your records out on your own terms.
The audit report, the DPA, and sub-processors
Now the three rows that separate a small vendor from a large one, and where I have to be most careful to tell the truth.
A SOC 2 report is an independent examination of whether a company's stated security controls actually operate over a period of time. It does not certify that a product is secure in some absolute sense; it confirms that the controls the company claims to have are the controls it really runs. That distinction matters, and I made the whole argument in a post on why SOC 2 is a starting line, not security. Here is the plain fact for this checklist: wrxstack does not have a SOC 2 report. There is no audited attestation waiting in a data room. If your procurement process requires one, this is a hard stop, and you should know it before a single call is booked.
A data processing agreement, or DPA, is the contract that governs how a vendor handles personal data on your behalf, the kind of document that privacy regulations expect between a company and its processors. A sub-processor list is the companion to it: the named third parties, such as hosting and email providers, that touch your data in the course of running the service. Serious buyers want both, and they want the sub-processor list kept current. wrxstack describes its data handling openly on the security page and the trust page, which is where these details live rather than buried in a sales deck.
The incident process
The last row asks what happens on the worst day. If there is a breach, how fast will you be told, in what form, and with what detail. A good vendor has a written process for detecting, containing, and disclosing an incident, and does not improvise it under pressure. This is less about a certificate and more about temperament, which is why I put real weight on it. I wrote about the shape of an honest disclosure in a post on how enterprise trust is earned slowly. The commitment wrxstack makes is direct notification from the person who runs the system, because there is no support tier standing between you and the truth.
| Checklist item | What it proves | Where wrxstack stands today |
|---|---|---|
| SSO (SAML / OIDC) | Central control of who can log in | Yes. Atlas supports SSO over SAML and OIDC. |
| MFA | A stolen password is not enough | Enforced through your identity provider via SSO. |
| SCIM provisioning | Automatic account create and remove | No. SCIM is not offered. |
| Named RBAC | Predefined roles and permissions | Permission model on the work graph, not named-role RBAC. |
| Audit log | A record of who did what, and when | Yes. Actions are logged on the work graph. |
| Data export | You can take your data and leave | Yes, via the public API. |
| SOC 2 report | Controls are independently examined | No. There is no SOC 2 report. |
| DPA and sub-processors | Contractual handling of personal data | Data handling described on the security and trust pages. |
| Incident process | Fast, honest breach notification | Direct notification from the person who runs the system. |
How to read a column full of mixed answers
A row of clean yeses is not the goal, and a vendor that claims one should raise your suspicion, not lower it. The honest picture of any small product is a mix, and the useful skill is reading the mix against your own needs. If you are a two-hundred-person company with a dedicated IT team, the SCIM and SOC 2 rows are not negotiable, and wrxstack is not your vendor yet. If you are a small team that wants central login, a real audit trail, and the ability to walk away with your data, the yeses on this list cover the controls that actually protect you, and the noes describe capabilities you may not need for a while.
What I refuse to do is fill in a row I cannot back up. This site runs an automated check that fails the build if any page claims a certification or a control the product does not have. The honesty on this page is not a rhetorical move. It is enforced in code, for the same reason the audit log exists: a claim you cannot verify is worth nothing.
Does wrxstack have a SOC 2 report?
No. There is no SOC 2 report and no other formal security certification today. If your procurement process requires one, wrxstack is not a fit yet, and that is stated plainly rather than deferred to a sales call.
Does Atlas support SSO and MFA?
Yes to SSO, over both SAML and OIDC, so it connects to your existing identity provider. MFA is enforced by that provider rather than by a separate scheme inside the app, which is the standard enterprise pattern.
Is SCIM provisioning available?
No. Atlas does not offer SCIM or directory sync. Accounts are not created and removed automatically from your directory. This matters most at large scale, which is exactly the buyer wrxstack is not the right fit for today.
Can we get our data out if we leave?
Yes. Atlas exposes a public API, so your records are reachable programmatically and export does not depend on a manual, vendor-controlled process. Easy exit is treated as a feature, not a threat.
Where are the data handling details written down?
On the security page and the trust page. Those pages describe what is and is not in place, including the limitations, rather than presenting only the favorable parts.
Who this checklist rules out
If your organization cannot onboard a vendor without a SOC 2 report, SCIM provisioning, and a signed enterprise agreement with guaranteed response times, this is not the product for you today, and I would rather say so on this page than after you have invested a week in evaluation. The controls wrxstack does have, SSO, an audit log, and a public API for export, are real and useful, but they do not add up to the full enterprise package that a large, regulated buyer needs. Match the list to your actual requirements before you spend anyone's time.