Privacy Policy

ID Posture (idposture.io) is operated by SOLUTIONWARE PTY LTD (ABN 81 630 109 643), trading as ID Posture (“ID Posture”, “we”, “us”). We are bound by the Australian Privacy Principles (APPs) in the Privacy Act 1988 (Cth).

ID Posture is a security posture management product, identity-first, that also covers Azure resource configuration (databases, networking, Key Vault, storage, and container services). Organisations (“customers”) connect their Microsoft Entra ID tenant (and optionally their Azure subscriptions) to ID Posture so we can scan it, evaluate it against a fixed set of security findings, and present a posture score and remediation guidance back to that organisation's own staff.

This policy covers two different things, and we've kept them separate on purpose because they involve different information:

• Your account with us: if you're a person who signs into the ID Posture portal (a customer's staff member, or an ID Posture team member).
• Your organisation's identity data: if your employer or organisation has connected its Microsoft Entra ID tenant to ID Posture, information about your account (display name, sign-in status, role assignments, MFA status, etc.) may be read by our scanner as part of assessing your organisation's security posture. We are not the party who decided to do this; your organisation is (see “Our relationship with your organisation” below).

3.1 Your ID Posture portal account

When you sign into the ID Posture portal, you authenticate with your own Microsoft work or school account (or, for our staff, an ADEE-controlled account); we never collect or store a password. From that sign-in, we hold:

• Your name and email address, and your Microsoft account identifier (object ID)
• Your role within your organisation's ID Posture account (Admin or Reader)
• Basic account activity: last login time, invitation history

This is the only personal information we store about you as our own customer or user, not derived from a scan, but directly from you signing up or being invited.

3.2 Identity data read from a connected Microsoft Entra ID tenant

When your organisation's administrator connects their Microsoft Entra ID tenant to ID Posture (via Microsoft's own admin consent flow), our scanner reads a defined, fixed set of directory metadata using read-only Microsoft Graph API permissions:

• User and guest account metadata: display name, user principal name, account status, licence assignment, sign-in activity timestamps, MFA registration status
• Application and service principal metadata: display name, owners, credential expiry dates (not the credential values themselves), granted permissions
• Conditional Access policy configuration
• Entra directory role assignments

If your organisation also connects its Azure subscriptions, we additionally read Azure role (RBAC) assignments at subscription, resource-group, and resource scope, via read-only Azure Resource Manager access.

If your organisation has enabled one or more of our optional Azure resource-configuration categories, we additionally read configuration metadata (not the data stored inside these services) for the relevant resource types: Azure SQL Server and databases, Cosmos DB accounts, Azure Cache for Redis and Azure Managed Redis, virtual network subnets and network security groups, Key Vaults, Storage accounts, and Azure Kubernetes Service clusters. For example: whether a resource requires Microsoft Entra ID authentication instead of a local credential, its public network access setting, and similar security-relevant configuration. Each category is a separate, explicit connection your organisation chooses to make, off by default.

We never collect or have access to: passwords, multi-factor authentication secrets, application secret or certificate values (only their expiry metadata), sign-in log content, email content, file content, or anything beyond the specific directory metadata listed above. Every permission we request is read-only, so ID Posture cannot make any change to your organisation's Microsoft 365 or Azure environment.

3.3 Marketing site, analytics, and general enquiries

Our marketing site (idposture.io) uses Google Analytics and Cloudflare Web Analytics to understand how visitors use the site (pages viewed, general location, device/browser type, referral source). This is aggregate visitor analytics, entirely separate from the scan data described in section 3.2, and it never touches anything about your organisation's connected tenant. These tools may use cookies or similar technologies to collect this information; the marketing site does not currently present a cookie-consent banner.

If you fill out a form on idposture.io or email us, we collect what you provide (name, email, company, message content) to respond to you.

We draw a hard line between two categories of data, by design:

• Structured scores and metadata (posture scores, finding counts, scan timestamps) are stored in an Azure SQL database.
• The underlying identity data, meaning the actual list of affected user accounts, applications, or role assignments behind a finding, is stored separately in Azure Blob Storage, in a dedicated storage container per customer.

As a deliberate design and compliance decision, we do not store display names, usernames, or email addresses from your connected tenant's user population in our SQL database at all; it is stored only in the segregated Blob storage described above. There are two narrow, specific exceptions, each limited to a single feature: (a) our own portal login accounts (section 3.1 above), and (b) two audit-style features (Drift Detection and Accepted Risks), which, if your organisation has switched them on, store a display name, object ID, and UPN domain snapshot of the specific object each drift or risk-acceptance record is about, because those features are unusable without being able to name the object on screen.

All of the above is hosted in Microsoft Azure's Australia East region. Access is protected by:

• Row-level security on every database table, so one customer's data is never queryable from another customer's session, even in the event of an application-layer bug
• All secrets and cryptographic keys held in Azure Key Vault, never in application code or configuration
• Certificate-based, read-only application authentication to your tenant: no client secret, no write permission, ever
• Encryption in transit (TLS) and at rest (Azure-managed encryption) throughout

We do not sell personal information, and we do not use it for advertising. We share it only with the service providers ("subprocessors") that make the product work:

• Microsoft Azure: hosts our infrastructure (database, file storage, application servers) in the Australia East region. Sees all data described above, as the underlying cloud host.
• Microsoft (Graph API / Azure Resource Manager): the source of the identity data itself; we read it, we don't send anything to Microsoft beyond standard API authentication. This is your own tenant's data, which Microsoft already holds.
• Azure Communication Services: sends transactional email (welcome emails, scan alerts, invitations). Sees recipient email address, name, and email content.
• Cloudflare: DNS, content delivery, and DDoS protection in front of our domains; also Cloudflare Web Analytics on the marketing site. Sees network and traffic metadata and aggregate marketing-site visitor analytics, not scan data content.
• Google Analytics: marketing site visitor analytics only. Sees marketing site visit data (pages viewed, general location, device/browser type), never scan data or portal account activity.
• GitHub: used internally to automatically diagnose scan-pipeline engineering failures. Receives operational telemetry only for a failed scan (an internal tenant identifier, scan identifier, status, and system error message), never your organisation's identity data or Azure resource configuration data described in section 3.2.

Scan-derived identity data is never stored outside Australia. Google Analytics, Cloudflare (used only for marketing-site visitor analytics and network delivery, not for any scan data), and GitHub (used only for internal engineering diagnostics, not customer scan data) may process data on infrastructure outside Australia as part of their global service.

We may also disclose information where required by law, or to protect the rights, safety, or property of ID Posture, our customers, or the public.

• Trial accounts: a trial runs for 30 days from the point your organisation connects its tenant. If it isn't converted to a paid account, we retain the data for a further 14 days (in case you change your mind) before it is permanently deleted.
• Paying customers: we retain data for the life of your subscription. Scan history has no automatic expiry, so you can review your posture trend over time.
• On disconnection or account deletion: we run a full deletion process across every system that holds your data, meaning the Blob storage container, all database rows, and any generated reports, within 30 days, not a soft “hidden from view” delete.
• Your own portal account activity log (if your organisation has this feature enabled) has a configurable retention window your organisation's administrator sets (30, 90, or 365 days), after which older entries are automatically purged.

Under the Australian Privacy Principles, you have the right to:

• Ask what personal information we hold about you and request a copy
• Ask us to correct information that is inaccurate or out of date
• Complain if you believe we've mishandled your information

For your ID Posture portal account, you can also ask your organisation's ID Posture administrator to remove your access at any time.

To exercise any of these rights, contact us at [email protected]. If you're not satisfied with our response, you can complain to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.

We comply with the Notifiable Data Breaches (NDB) scheme under the Privacy Act. If we experience a data breach likely to result in serious harm, we will notify affected individuals and the OAIC within 30 days of becoming aware of the breach.

If your employer or organisation is an ID Posture customer, they are the ones who decided to connect their Microsoft Entra ID tenant to our product, and they control what we're allowed to see (via the specific Microsoft Graph permissions they consent to) and for how long we keep it. In privacy law terms, your organisation is the data controller and ID Posture is the data processor. See our Data Processing Agreement for the detail of that relationship. Questions about why your organisation is scanning your account, or what they do with the results, should go to your own organisation, not to us.

We'll update the date at the top of this page whenever we make a material change, and for significant changes we'll notify customer administrators directly.

SOLUTIONWARE PTY LTD (ABN 81 630 109 643), trading as ID Posture
3 Bernard St, Mount Waverley VIC 3149, Australia
Email: [email protected]