Security

Digital Plattform Sverige AB, a Swedish company based in Linköping. The platform is built and operated by the same team — there is no outsourced operations provider between us and the running systems.

That team is small. We treat that as a control rather than a caveat: access is granted to named individuals, and the list of people who can reach production is short enough to be reviewed by reading it.

Each customer runs their own system with its own database, assembled from shared platform capabilities. Customer data is separated at the database level, not by a tenant column in a shared table.

Platform improvements land underneath every system without a migration project, which is what makes a shared capability set worth having.

This Trust Center is the primary document, and it is public so a reviewer can start without contacting us. A Data Processing Agreement is available on request.

For a security questionnaire, an architecture review or a specific control we have not covered here, contact info@digitalplattform.se and you will be answered by an engineer who works on the platform.

In the European Union. The platform runs on Amazon Web Services in the eu-north-1 region (Stockholm, Sweden), which is where compute, the platform database and file storage all live.

Transactional email is sent through Amazon SES in eu-west-1 (Ireland), also within the EU. One legacy environment runs on a dedicated server hosted in Sweden.

No customer data is stored outside the EU by the platform itself. The exception is a service a customer chooses to enable — see the Subprocessors page for which ones those are and where they process data.

Amazon Web Services. Physical and environmental security of the data centres is AWS's responsibility under their shared responsibility model; everything above the hypervisor is ours.

We run on our own AWS accounts rather than a reseller's, so account-level controls, billing and the audit trail belong to us directly.

The platform database runs as a self-hosted MongoDB replica set, so a node failure does not take the data layer down and a member can be replaced without a full restore.

Application servers run on separate instances from the database. Backups are taken independently of the replica set, so a data-loss event and an availability event are recovered by different mechanisms.

Planned: multi-availability-zone failover for application servers. Today the recovery path for a lost instance is a rebuild from the daily machine image, not an automatic failover.

Public endpoints terminate TLS at nginx and nothing else is exposed. Administrative access is over SSH on a non-standard port, restricted to key-based authentication — password login is disabled.

The platform database is not reachable from the public internet. It accepts connections on the internal network only.

Planned: a formal network segmentation review and documented ingress rules per service tier.

Yes, and the separation is enforced in the platform rather than by convention. Production, staging and local development are distinct environments with distinct configuration and distinct credentials.

Non-production environments are prevented from acting on the outside world: they do not send real email or SMS, and they never process payments. Those are per-environment policies in the platform's configuration, not something an engineer has to remember to switch off.

A developer working on a feature does not hold production credentials as a side effect of that work.

All public traffic is HTTPS. TLS 1.2 or higher is required, certificates are issued by Let's Encrypt and renewed automatically, and plain HTTP is redirected rather than served.

Traffic between the application and the platform database stays on the internal network and is not exposed to the public internet.

Backups are encrypted at rest. The AWS Backup vault holding machine images is encrypted with AWS KMS, and database backups are written to S3 in the same region.

Application secrets are encrypted at rest independently of the storage layer, as described in the next answer.

Planned: full-disk encryption on the primary database and application volumes. We have not enabled it on the existing volumes, and we would rather state that here than let a reviewer assume otherwise.

Secrets never live in source control and never live in plain files on a server. Each system and environment pair has its own RSA key pair in an encrypted vault. The private key is encrypted with AES-256-GCM under a key derived by scrypt from an operator password, and the secret values themselves are stored as a hybrid-encrypted blob under that key pair.

At runtime a server decrypts the blob into memory. The on-disk cache a server keeps is readable only by the service account that owns it.

The practical consequence: reading a database dump, a backup archive or a source repository does not give an attacker working credentials.

Key pairs are generated per system and environment, so compromising one environment's key does not expose another's. Each vault entry records when it was last rotated.

Keys for AWS-managed encryption — the backup vault — are managed by AWS KMS within our own account.

Planned: a fixed rotation schedule with automated enforcement. Rotation is currently an operator action performed when circumstances call for it rather than on a timer.

Email and password is the standard method. Two-factor authentication by emailed one-time code can be enforced for every login to a system, and it is configured per system and per environment rather than left to each user to opt into.

BankID is supported for Swedish electronic identification where a system requires verified identity.

Planned: SAML 2.0, OpenID Connect and enterprise single sign-on. These are not implemented today. If SSO is a requirement for your organisation, tell us during evaluation rather than after — it changes the timeline.

Yes, as an emailed one-time code on top of the password. It can be made mandatory for a whole system, so it is an administrator's decision rather than a per-user preference.

Planned: TOTP authenticator apps and hardware security keys. Email is the only second factor available today.

Role-based access control with a role hierarchy — viewer, user, admin, superadmin — where a higher role inherits the permissions of the ones below it. On top of roles, access rules can be attached to specific users or to groups, and to specific resources or individual records.

Permissions are evaluated per resource and per action: read, write, create and delete are separate. Group membership is the normal way to grant access at scale, and only active groups grant anything.

Access decisions are made server-side on every request. Hiding a control in the interface is not how access is enforced.

Through key-based SSH to named accounts. Password authentication is disabled, and there is no shared administrator login.

Production credentials are held in the encrypted vault and decrypted per operator session rather than distributed as files. Deployments run from an operator's own machine against a specific environment, so an action against production is always attributable to a person.

Planned: formal periodic access reviews with a recorded outcome. Today the access list is short and reviewed when it changes, but that review is not yet a scheduled, documented control.

Only when there is a reason to: a support request you have raised, or an incident affecting your system. We do not browse customer data.

Where a system's data is accessed through the application, the audit log records who did it, what they touched and when — the same log that records your own users' access, with no separate unlogged staff path.

Each entry records the acting user and their email address, the account the action belonged to, the action itself, the type of resource and its identifier, the client IP address, a severity level and free-text detail where the action carries any.

The actions covered are read, write, create, delete, login and denied access. A refused access attempt is recorded as deliberately as a successful one — an access-denied trail is what shows probing.

Yes. Logins are audit-logged with the acting user and originating IP address, as are access denials. Failed authentication and administrative actions performed through the application go into the same trail.

Yes. Infrastructure metrics and alarms run in Amazon CloudWatch across the fleet, covering host and service health.

Planned: centralised log aggregation with search and retention policies across application, system and audit logs. Today those logs live on their respective hosts and in the platform database rather than in a single searchable store.

Yes. The audit trail is your data — it belongs to your system's database and can be exported like anything else in it. Ask and we will show you how to reach it for your system.

Planned. We have not commissioned an independent third-party penetration test of the platform, and we are not going to imply otherwise.

If a penetration test is a condition of your procurement process, say so during evaluation. We will discuss scope and timing, and a customer-commissioned test against a staging environment is something we will accommodate.

Dependencies are updated as part of ordinary development, and the platform runs a single shared dependency set rather than one per customer — so an update reaches every system at once instead of being applied per installation.

Planned: automated dependency vulnerability scanning wired into the build with a defined remediation window. Dependency review is currently a manual activity.

Operating system and package updates are applied by operators as part of maintenance, and machine images are captured daily, so a patch that goes wrong is recoverable to the previous day's image.

Planned: a documented patch cadence with tracked SLAs by severity. We do not currently commit to a fixed window for applying a given severity of patch, and stating one here that we do not measure would be worthless to you.

Email info@digitalplattform.se with enough detail to reproduce the issue. Include the affected URL or endpoint, the steps, and what you were able to demonstrate.

We ask that you give us a reasonable opportunity to fix an issue before publishing it, that you do not access, modify or delete data belonging to anyone else, and that you do not run tests that degrade service for other customers. Within those bounds, we will not pursue legal action over a good-faith report.

We will acknowledge your report, tell you what we found, and tell you when it is fixed. Planned: a bug bounty programme. There is no paid reward today.

Changes are reviewed against a written engineering rulebook that covers structure, data access and security-relevant patterns. The rulebook is enforced in review rather than left to individual judgement, which is what makes review consistent across a small team.

The platform's shared architecture is itself part of this control: data access, permission checks and validation are implemented once in the platform rather than reimplemented per feature, so a review is checking that a feature used the right mechanism, not whether it invented a safe one.

Yes. The platform has unit and integration test suites, plus end-to-end browser tests that drive the real application. Tests are run before a release, and a release does not proceed on a failing suite.

Planned: continuous integration running the full suite automatically on every change. Test runs are currently triggered as part of the release process rather than by a hosted CI pipeline.

A change goes to staging before production. Each release is tagged, and a production release deploys the exact commit that was released to staging and verified there — not a rebuild from the latest state of the branch.

Every release takes a snapshot beforehand, and there is a documented rollback runbook. Rolling back is a normal operation rather than an emergency improvisation.

Releases are performed by an operator rather than automatically on merge. That is a deliberate trade: fewer automated deployments, and a named person accountable for each one.

Customer systems are assembled from platform capabilities, so most change arrives as a platform improvement that has already been through staging and verification before it reaches any customer.

Changes specific to your system are agreed with you first. You are not a test environment for someone else's feature.

Every server backs itself up daily to encrypted object storage in the same EU region, on an automated schedule, with a 7-day retention window enforced by a storage lifecycle rule. Backups are held offsite from the server that produced them — there is no reliance on a local copy surviving.

The platform database is additionally backed up with a continuous operation log, which allows recovery to a point in time rather than only to the last nightly snapshot.

Machine images of every server are captured daily and retained for 3 days, so a whole host can be rebuilt rather than reinstalled.

Restores are performed from these backups in practice, and the restore procedure is documented as a runbook rather than reconstructed under pressure. It requires the archive to be verified as intact before anything is overwritten, and a fresh pre-restore safety copy to be taken first, so a restore that goes wrong is itself reversible.

Planned: scheduled restore drills with recorded results. Restores today are verified when performed rather than on a calendar.

We do not publish a recovery time objective or recovery point objective, because we do not yet measure recovery against one and a number we have not tested would not be worth anything to you.

What we can state factually: backups run daily, the platform database supports point-in-time recovery from its operation log, and full machine images from the previous day exist for every server.

Planned: measured and published RTO and RPO targets, backed by drill results.

You get it. Your data is exportable at any time in a machine-readable form, and export is not conditional on why you are asking or on the state of a commercial relationship.

First contain, then recover, then explain. An incident is triaged for scope and customer impact, contained, and recovered using the documented restore and rollback procedures. The state of affected systems is preserved where doing so does not delay recovery, so the cause can be established afterwards.

The same people who build the platform respond to its incidents. There is no escalation queue between a report and someone who can act on it.

By direct contact to the people you have named for it, not by a status page you would have to be watching. You will be told what happened, what it affected, what we did and what you need to do — including when the answer is nothing.

We will contact you while an incident is ongoing rather than only once it is resolved, even when we do not yet have a complete picture. A partial update on time is worth more than a complete one after the fact.

Where we act as data processor and become aware of a personal data breach, we notify you as controller without undue delay, so that you can meet your own 72-hour notification obligation to your supervisory authority under GDPR Article 33.

The notification will describe what we know: the nature of the breach, the categories and approximate volume of data involved, the likely consequences, and the measures taken or proposed. Where we do not yet know something, we will say so rather than delay the notification until we do.

For an incident that affected your system, yes — you get a written account of what happened, why, and what changed as a result.

Internally, incidents and their causes are recorded so that the fix lands in the platform rather than in one operator's memory. Planned: publishing postmortems for platform-wide incidents on the Status page.

You do. Data you put into your system, and data your system generates, belongs to your organisation. We do not claim ownership of it, and we do not acquire rights to it by processing it.

We process it to run the service you are paying for, on your instructions. Where personal data is involved you are the data controller and we are the processor.

No. Customer data is not used to train models, ours or anyone else's. See the Responsible AI page for exactly what happens to data that passes through an AI capability.

Yes, at any time, in a machine-readable form. Your system also runs on a standard database rather than a proprietary store, which means the export is a real dataset rather than a report of one.

Yes. On request we delete customer data from the live system, and it ages out of backups as those backups reach the end of their retention window rather than being surgically removed from every archive.

That retention window is stated on the Privacy page along with the deletion process. If you need a specific deletion timeline for a contractual or regulatory reason, tell us and we will confirm in writing what we can commit to.