Service Level Agreement

ID Posture is built entirely on Microsoft Azure and other managed cloud services. This SLA reflects that directly: we commit to the same standards our own infrastructure providers commit to us, for the exact services we run, and we don't promise better availability than Azure itself guarantees. We also don't take responsibility for an outage caused by Microsoft Azure, Cloudflare, or another subprocessor failing on their own end. See Exclusions below.

This SLA covers the ID Posture platform and API: the systems that scan your tenant, evaluate findings, and serve data to the customer portal. It does not cover the hosting of the customer portal or marketing website themselves.

In practice, every interaction with ID Posture goes through the portal, which then calls the platform underneath. If the portal itself is unreachable, you won't be able to reach your dashboard even though the platform remains technically available. Portal and marketing site hosting are addressed separately in the Exclusions section below.

We commit to 99.9% monthly uptime for the ID Posture platform and API. That figure is the floor across the Azure services the platform runs on, each backed by Microsoft's own currently published Service Level Agreement:

• Azure Functions (our scanning, processing, and API services): 99.95%
• Azure SQL Database (scores, findings, accounts, billing): 99.99%
• Azure Blob Storage (raw and processed scan data): 99.9%
• Azure Communication Services (transactional email): 99.9%

Our 99.9% commitment is deliberately conservative, not an average: two of the four services above individually guarantee a higher figure than what we commit to.

Two components fall outside the availability commitment above:

• Customer portal and marketing site hosting -- these run on a free hosting tier that carries no SLA from Microsoft at all. Every other component above runs on a paid tier with a real, published guarantee.
• Cloudflare, which sits in front of every ID Posture domain for DNS, content delivery, and DDoS protection -- our current plan carries no contractual SLA, though Cloudflare's real-world reliability track record is strong regardless.

Support response times are our own operational commitment, not an Azure-backed SLA:

• Standard Support (included for every customer): first response by the next business day, AEST business hours, Monday to Friday.
• Priority Support (drawn from a customer's prepaid support hours): first response within 4 business hours, AEST business hours, Monday to Friday.

Neither tier includes weekend or after-hours coverage today. If your organisation needs that, get in touch to discuss a dedicated arrangement.

Recovery Time Objective (RTO): 4 business hours from detection. Azure doesn't publish a recovery-time figure the way it publishes an availability percentage; RTO is inherently about how fast we act once something breaks, so this is our own commitment, measured from when we detect an incident rather than when it began. Outside business hours, response begins the next business day, matching Standard Support's own commitment.

Recovery Point Objective (RPO), Azure SQL Database: 10 minutes. This is Microsoft's own documented backup cadence for the database tier we run -- transaction log backups approximately every 10 minutes, on top of daily differential and weekly full backups.

Recovery Point Objective, Blob Storage (raw and processed scan data): near-zero. Scan data is written synchronously to three copies within the same Azure datacenter before a write is acknowledged, so an ordinary storage failure loses nothing.

Both recovery points above apply within a healthy Australia East region. Our backups are stored locally within Australia, consistent with the data-residency approach described on our Security page -- which means a genuine regional outage affecting Australia East itself sits outside what either recovery point can restore from. An event of that scale is covered by the Exclusions below, not by a specific recovery time.

If our monthly platform/API availability falls below the 99.9% commitment in Section 3, you're entitled to a service credit against that month's platform-related fees:

• 99.0% to 99.9% availability: 5% credit
• Below 99.0% availability: 15% credit

Credits are capped at 25% of fees in any rolling 12-month period, and apply to availability only -- the RTO and RPO figures in Section 6 are descriptive commitments, not separately credited.

To request a credit: email [email protected] within 30 days of the end of the affected month, referencing the period in question. We'll confirm the shortfall against our own monitoring and apply any credit owed to your next invoice.

No commitment is made, and no service credit is owed, for unavailability caused by:

• Any outage, degradation, or maintenance of Microsoft Azure itself, including a regional outage affecting Australia East. Our commitment above is a pass-through of Azure's own published SLA for each component, not something layered on top of it.
• Any outage of Cloudflare or another subprocessor, as listed in our Data Processing Agreement.
• Scheduled maintenance, announced with reasonable advance notice.
• Force majeure events.
• Issues originating in your own network, Microsoft 365/Entra ID tenant, or Azure subscription (for example, a Conditional Access policy on your side blocking our service account).
• Denial-of-service or other attacks against the Service, to the extent outside our reasonable control.
• Unavailability of the customer portal or marketing site's own hosting -- addressed separately in Section 2 rather than covered by this list.