Data processing annex

Data controller

The customer, for everything Securenix reads in their Microsoft 365 tenant and their on-premises environment.

Data processor

Technix IT AB, org. no. 559237-0711.

Hosting

swedencentral

Microsoft Azure. App Service, Azure SQL and Key Vault all run in the same region; nothing is copied to another region.

Direction

Read-only

Securenix holds read permissions only and never writes anything in a customer tenant. A write permission would be a new consent, not a new setting.

§ 1

Sources

Securenix reads from four places and nowhere else. Two carry personal data about the customer's people, one carries none, and the fourth is Technix's own staff.

	Source	Owner	Transport	Frequency	Personal data
1	Microsoft 365 and Entra ID	Customer	Microsoft Graph, app-only token after admin consent	Per scan, on demand	Yes
2	Public DNS	Public	DNS resolver, server-side	Per scan, on demand	No
3	On-premises collector	Customer	HTTPS upload with a per-customer token	Per upload	Yes
4	Technix staff sign-in	Technix	OpenID Connect id token	Per sign-in	Yes

There is no schedule: a scan runs when a technician starts one, and an on-premises audit exists only if someone ran the collector. Nothing is polled in the background.

§ 2

Permissions the customer consents to

Application permissions

RoleManagement.Read.DirectoryDirectory.Read.AllOrganization.Read.AllSecurityEvents.Read.AllPolicy.Read.AllAuditLog.Read.AllDomain.Read.AllDeviceManagementConfiguration.Read.AllDeviceManagementManagedDevices.Read.AllUser.Read.AllSharePointTenantSettings.Read.All

The consent link asks for .default, which grants exactly the permissions configured on the app registration — Securenix can never name a scope the registration does not already hold. The list at the moment of consent is stored on the consent record, so it is known who has to consent again if it changes.

Every permission is a read permission. There is no write scope, and adding one would mean a new consent for every customer rather than a configuration change. Each check declares the permissions it needs, and the list above is exactly their union.

Not read

No mailbox, file, SharePoint, OneDrive, Teams or calendar content. No password hashes and no secrets. Sign-in logs are read only for the legacy-authentication check, over the last 30 days, and only the client app and the account are kept.

§ 3

What each control area reads

Every check asks Graph for named properties with $select, follows paging, and stores as evidence only what the finding has to show. Names and addresses from Graph are always rendered as plain text, in the app and in the report.

Control area	Endpoints read	Kept as evidence
Identity and administrators	/directoryRoles, /directoryRoles/{id}/members, /roleManagement/directory/roleEligibilityScheduleInstances, /subscribedSkus, /reports/authenticationMethods/userRegistrationDetails, /users	Number of administrators per privileged role; user principal name and display name of administrators without a registered MFA method, of break-glass candidates, and of privileged roles held on everyday accounts.
Secure Score	/security/secureScores, /security/secureScoreControlProfiles	Score, maximum and the top improvement actions. No personal data.
MFA and Conditional Access	/policies/identitySecurityDefaultsEnforcementPolicy, /identity/conditionalAccess/policies, /reports/authenticationMethods/userRegistrationDetails, /auditLogs/signIns	Policy names and states; the number of users without MFA and at most 50 of their user principal names; at most 20 accounts and the client apps seen in successful legacy sign-ins over the last 30 days.
Domains and email security	/domains	Verified domain names and their SPF, DKIM and DMARC records. No personal data.
Intune and device management	/deviceManagement, /deviceManagement/deviceConfigurations, /deviceManagement/deviceCompliancePolicies, /deviceManagement/configurationPolicies, /deviceManagement/intents, /deviceManagement/managedDevices, /deviceAppManagement/mobileApps	Policy, baseline and app names with assignment state; device name, operating system, compliance state and last check-in per managed device. No device owner is read.
Quick checks	/users, /policies/authorizationPolicy, /admin/sharepoint/settings, /organization	Guest count and guest user principal names; licensed accounts without a sign-in for a long period, with their last sign-in date; the user-consent and external-sharing settings; the tenant's security and technical notification addresses.

The partner-relationship area of the specification is not built: the GDAP API can only be read from the partner's own tenant, so Securenix's app-only token in the customer tenant is on the wrong side of that interface. No permission is requested for it.

§ 4

DNS lookups

SPF, DKIM and DMARC are public DNS records and need no tenant permission. Lookups run server-side and only for domains on the customer's stored list: the tenant's verified domains from Graph plus any domain a technician added on the customer page, validated on the way in. A host name never travels from a request into the resolver.

TXT <domain> · TXT _dmarc.<domain> · CNAME/TXT selector1._domainkey.<domain> · CNAME/TXT selector2._domainkey.<domain>

The records themselves are public policy data and contain no personal data. Results are not cached between scans.

§ 5

On-premises collector

Optional, and used only where the customer has an on-premises environment and agrees to it. A technician downloads a per-customer PowerShell script, runs it inside the customer's network, and it uploads one JSON document over HTTPS with an expiring, revocable token bound to that single customer. Securenix never connects to the customer's network itself.

Active Directory

Password policy, privileged group membership, stale and disabled accounts, accounts with non-expiring or old passwords, trusts, LAPS, domain controller and hybrid configuration. Account names and group memberships are personal data.

Servers

Operating system and patch level, firewall, SMB and NTLM configuration, TLS, RDP, endpoint protection, backup, BitLocker, event logging and local administrators. Server names and local account names are included.

The uploaded document is kept verbatim as evidence, together with the findings derived from it, and is covered by the customer deletion. The upload is treated as untrusted data and is only ever rendered as plain text.

§ 6

Technix staff sign-in

Sign-in is Entra ID against the Technix tenant, and access requires membership in one Entra security group. These claims are read from the id token:

oid, preferred_username, name

They live in the session cookie for the length of the session. The user principal name is stamped on audit rows and on the scans and links the technician creates. There is no separate sign-in table, and no IP address or user agent is stored.

§ 7

What Securenix generates

Beyond what it reads, Securenix stores records of its own. All of them except the audit log are owned by one customer and are erased with that customer.

Record	Contents	Purpose
Customer	Company name, Entra tenant id, technician notes and any manually added domains.	The aggregate everything else hangs off, and the erasure path.
Consent record	Consenting tenant id, status, the permission list at the time, timestamps for grant and revocation, and any error code.	The authority for whether a scan may run at all.
Scan run	Start and finish, status, health score, and the technician who started it.	One complete snapshot; written before the first Graph call so an attempt is never lost.
Finding and evidence	Check id, verdict colour, severity, text as resource keys, and the evidence the check saw as JSON. The evidence is the only place personal data appears.	The verdict and what it rests on, so a technician can act on it.
Report link	SHA-256 hash of a 256-bit token, language, expiry, revocation, view count and time of last view. Neither the token itself nor an IP address or user agent is stored.	Handing the report to the customer without giving them a log-in.
Upload token	SHA-256 hash of a 256-bit token bound to one customer, with expiry, revocation and use count.	Lets the collector upload without a log-in; the customer is derived from the token, never from the upload.
Audit log	Action, acting technician, company name, the object concerned, and neutral details such as an expiry date or a permission list.	Traceability. Survives the deletion it records and holds no personal data of the deleted customer.
Consent evidence	The event (invitation sent, terms accepted, consent granted), its time, the company name, the email address of the invitation's recipient or of the person who accepted the terms, the terms version and the consenting tenant id.	Proof that the customer agreed to the scan. Survives the deletion of the customer.
Operational logs	Azure Monitor and Application Insights: requests, exceptions and Graph correlation ids. The token in a report URL is redacted before the request is logged, and HTTP logs are not shipped to the workspace.	Operations and troubleshooting. 90 days in production.

Credentials and secrets

The scanning app authenticates with a certificate from Key Vault in Azure, reached with a managed identity. Access tokens are never stored: they live in memory keyed by tenant id for the length of a run. The database uses Entra-only authentication, so no connection string holds a password. No secret, token or certificate is ever written to a log.

§ 8

Isolation and retention

Every customer-owned row carries the customer id, and every query is scoped by it explicitly. Loading a run, finding or report by id also verifies that it belongs to the customer in the route — a wrong id gives a 404, never another customer's data.
Before anything is persisted, the tenant id in the acquired token is compared with the customer's stored tenant id. A mismatch means the scan reads nothing and writes nothing.
Only Technix staff in one Entra security group can sign in, enforced by a global authorization policy rather than by hidden buttons. The shared report link is the only anonymous surface, and it shows one scan of one customer with no way into the app.
Scans and findings are append-only: a terminal outcome is never rewritten and a new scan is a new run. There is no automatic expiry in this version — data is kept until the customer is deleted.
Deleting a customer cascades to consent records, runs, findings, evidence, report links, on-premises audits and upload tokens, and leaves a single audit row without personal data.

§ 9

Special categories

Securenix processes no special categories of personal data under Article 9, and no personal identity numbers. Nothing it reads is content: names, addresses and device names appear only as identifiers of the accounts and machines whose security configuration is being assessed.

Contact

Questions about this annex, or about a source you do not recognise here, go to Technix at the address below.

dpo@technix.se Personal data in Securenix