Most delivery tools are easy to trial and hard to approve. DigitalStack360 holds client work, commercial rates, and engagement history, so the controls that matter to a security team are part of the product rather than a roadmap promise. This page describes what is actually built.
Enterprise SSO through SAML with enforcement policies, MFA and passkeys, and controlled break-glass access.
Hierarchical permissions evaluated down to module and submodule, with reusable templates and explicit deny.
Rates and margins are role scoped, so commercial figures stay visible only to the people who should see them.
A workspace wide audit log spanning every project plus account level events, with export and saved views.
Every uploaded file is scanned for malware and verified by the server before it is written to storage.
Strict per account isolation, with row level security in the database and an authorization layer above it.
Sign in is something your IT organization should control, and revoking someone in one place should be enough.
Connect your identity provider and let it own who gets in. Provisioning, deprovisioning, and password policy stay where your IT team already manages them.
Once SSO is connected, an account can require it. Members sign in through your identity provider rather than through a local credential.
Enforcement is not a lockout risk. Designated break-glass access lets a named administrator regain entry if the identity provider is unreachable.
For accounts that authenticate directly, multi factor authentication and passkeys are supported, with recovery codes so a lost device does not become a lost account.
People who work across more than one account switch between them explicitly. Each account is a separate authorization context, not a merged view.
Getting into the platform and getting into a specific part of it are separate decisions. Permissions are hierarchical and are evaluated down to the module and submodule level, which is what makes it possible to give a client stakeholder a view of delivery without giving them a view of commercials.
Rate and margin visibility is treated as its own permission rather than a byproduct of project access. A delivery lead can run the work without seeing what the work bills at, and a contractor or client contact can sit inside a project without ever seeing the economics of it.
Audit is account wide rather than per project. Activity across every project and account level events sit in a single log, so answering who changed what does not require assembling evidence from separate places.
Every uploaded file is scanned for malware before it reaches storage. The file is scanned against the scanning service from the client, and the server independently verifies both the scan result and the file checksum before the object is stored. A file that fails either check is rejected rather than quarantined after the fact.
Data is isolated per account. Row level security policies in the database scope rows to the account that owns them, and an authorization layer above the database applies the permission model on top of that. The two are independent, so a mistake in application code does not by itself expose another account's data.
Connecting a system means handing over a credential, so those credentials are encrypted at rest rather than stored in the clear. Calendar tokens are encrypted as well.
Anything that can read the platform over an API is a credential your security team has to reason about, so it is issued narrowly and can be pulled back.
Keys carry only the scopes they were issued for and are revealed once at creation. After that the value is not retrievable, only rotatable or revocable.
Third party and partner applications authorize through OAuth 2.0. The consent step names the account and the specific scopes being granted.
Webhook deliveries are signed so your receiver can verify they came from DigitalStack360, and signing secrets can be rotated without downtime.
Limits are applied per key, so one integration cannot exhaust capacity for the rest of the account.
AI features are subject to the same permission model as the rest of the platform, and usage is metered and rate limited per account. Firms that want AI activity to run through their own provider relationship can bring their own provider key, so the requests are made against their account under their own terms with that provider.
If you believe you have found a security vulnerability in a DigitalStack360 product, please report it privately so it can be investigated and fixed before public disclosure. Email [email protected] with the affected URL or component, steps to reproduce, the potential impact, and any supporting evidence.
We ask researchers to act in good faith, to avoid accessing or modifying data that is not theirs, and to avoid disrupting service for other users. We will work with you in good faith in return, and we do not pursue legal action against researchers who report in line with these guidelines.
DigitalStack360 is built to support enterprise security reviews, and questionnaires are welcome. Send yours and we will work through it directly. If it would help to see the controls in the product, we can walk your team through them live.