Security, Auditing, and Confidentiality

At a glance

The district runs its email, files, and online tools on a Microsoft 365 tenant that serves around 330 accounts: members, committees, shared mailboxes, and club lookup accounts. This page explains, in plain language, exactly how that system is protected and how your information is treated.

• Every account is protected by multi-factor authentication (MFA). A password alone is never enough to sign in.
• Access is layered. You can only see the mailboxes, sites, and tools that your role gives you. Nobody gets "everything" by default.
• Everything significant is recorded. Sign-ins, administrative changes, file access, and every change to sensitive registers are logged automatically, including what administrators do.
• Support is consent-based. The IT team does not read your email or files to fix a problem unless you ask us to or give us permission, and any access we do have leaves an audit trail.

Where your data lives

The district tenant is registered in Australia, and Microsoft stores the data for its core services (Exchange email, SharePoint and OneDrive files, and Teams) at rest in Microsoft's Australian data centres. Data is encrypted in transit (TLS) whenever it moves between your device and Microsoft, and encrypted at rest on Microsoft's servers.

Microsoft provides the platform under its nonprofit program, but the data in it belongs to the district. Microsoft does not read your email or documents for advertising, and district data is never sold or shared outside the organisation.

How sign-in security works

Signing in to any district account involves two layers:

1. Your password. Set by you and known only to you. When the IT team creates or resets an account, we issue a temporary password that Microsoft forces you to change at your first sign-in. That means the IT team never knows the password you actually use.
2. Multi-factor authentication (MFA). Every account must register a second factor, normally the Microsoft Authenticator app on a phone. Sign-ins from new devices or locations prompt for it, so a stolen password on its own cannot get into your account.

What a password has to be

Microsoft enforces a minimum standard on every password in the tenant, and the district adds protection on top of it:

• Length and mix. A password must be between 8 and 256 characters and use at least three of the four character types: uppercase letters, lowercase letters, numbers, and symbols. It cannot contain your account name. We recommend a passphrase of a few random words, which comfortably beats the minimum and is easier to remember.
• Weak and breached passwords are blocked. Microsoft's global banned-password protection is always on. Even a password that technically meets the length and mix rules is rejected if it is a known-weak or previously-breached one (for example anything close to "Password1"), so a compliant-looking but guessable password cannot be set.
• Repeated wrong guesses lock the account. Smart lockout temporarily locks an account after a run of failed sign-ins and lengthens the delay if they continue, which blunts password-guessing attacks without a real user ever noticing.
• Passwords do not expire. The tenant does not force routine password changes. Current security guidance (Microsoft and NIST) is that scheduled expiry pushes people towards weaker, patterned passwords, so we rely on a strong password plus MFA and change a password only when there is a reason to (a reset request, or a suspected compromise).

Self-service password reset is switched on for the tenant, so if you forget your password you can reset it yourself at aka.ms/sspr using your registered MFA method, without needing to contact IT at all. See Forgot Your Password? for the walkthrough.

Access levels: who can see what

Access in the district tenant is layered. Each layer only adds what that role genuinely needs, which is why most members never see most of the system.

A few deliberate choices sit behind this:

• Least privilege. Day-to-day support work is done with service administrator roles scoped to a single service, not with Global Administrator rights. Billing is held separately by the Finance Committee Chair, not by IT.
• Guests are restricted. External guest accounts are set to the most restrictive level Microsoft offers: a guest cannot browse the directory or see who else is in the organisation.
• Roles follow positions, not people. When a committee or board role changes at the July changeover, access moves with the role. Outgoing officers lose access; incoming officers gain it.

Who holds administrator access

Administration of the tenant is split across the District Microsoft 365 team and a couple of specific roles, so no one person quietly holds everything and every administrative action can be traced to who performed it.

A few things follow from this:

• Least privilege in practice. Everyday support is done with the single-service roles, not Global Administrator. Global Admin is only used for tasks that genuinely need it.
• Separation of duties. Finance sits with the Finance Committee Chair, kept apart from IT, so system administration and money are not in the same set of hands.
• Dedicated admin accounts. Administration is done from dedicated admin-only accounts, kept separate from the everyday accounts those same people use for their own email and files. The everyday accounts carry no administrative rights at all: high-privilege access lives only on the separate admin accounts. Isolating high-privilege access from day-to-day activity is standard security practice and means an everyday sign-in never carries admin rights with it.
• The IT team is not "everyone in IT". Being on the IT team does not by itself grant tenant administration. Roles are assigned to specific accounts, and someone can help with support (for example DACdb or the website) without holding any Microsoft 365 admin role.
• The emergency ("break-glass") account. One highly-secured Global Admin account exists only as a recovery path if the named administrators are ever locked out. It is not used for day-to-day work, and any sign-in to it is logged.

Auditing: what is recorded

Microsoft 365 keeps detailed automatic logs of activity across the tenant. This is not optional and cannot be quietly switched off by an administrator without that change itself being logged.

The important consequence: administrators are watched by the same system they administer. If an administrator resets a password, opens a shared mailbox, or changes someone's access, that action is attributable to their named account and visible in the logs. There is no anonymous administration.

On top of the automatic logs, the IT team runs periodic access reviews: scripts that report exactly who holds which roles and who has access to what across the tenant. That turns access from something that quietly accumulates into something that is checked and trimmed, so stale or unnecessary access is found and removed rather than lingering.

How support works with your confidentiality

All support goes through the shared inbox at support@rotary9660.org.au, so requests are seen by the team rather than sitting in one person's mailbox. From there, the guiding rule is simple: we fix problems with the least possible access to your content, and we do not look at your email or files without your permission.

flowchart TD
    A["You email the
support inbox"] --> B{"Fixable without
touching your
content?"}
    B -- "Almost
always yes" --> C["Fixed from admin
settings only.
Your email and files
are not opened."]
    B -- "Rarely" --> D["We explain what we
need to see
and ask permission"]
    D --> E["Temporary access,
every action logged"]
    E --> F["Fixed, then
access removed"]

What that means in practice:

• Most fixes never touch your content. Password resets, MFA changes, licence problems, and access requests are all done from the admin side without opening your mailbox or files.
• Content access is by consent. If a fault genuinely requires someone from IT to look inside your mailbox or OneDrive (for example a corrupted item or a mail-flow fault), we tell you what we need to see and why, and only proceed with your agreement. That access is temporary, and the grant and every action under it appear in the audit logs described above.
• Your password stays yours. Temporary passwords must be changed at first sign-in, so IT never holds a working password for your account.
• What you tell support stays in support. Details you share with the IT team are used to resolve your request and are not passed around the district.
• Outbound email carries a confidentiality notice. Mail sent from district accounts automatically has the district's confidentiality disclaimer applied at the server, so misdirected email carries a clear statement that it is for the intended recipient only.

Extra protection for youth protection data

The Youth Protection Compliance Register holds the most sensitive information in the tenant, so it gets stricter handling than everything else:

• Tiered access. Ordinary members and club accounts searching the register see only name, clearance type, status, and expiry date. Reference numbers, attached documents, and notes are visible only to the five authorised compliance administrators (the Youth Protection Chair, Youth Exchange Chair, District Governor, and district administrators).
• A dedicated audit list. Every change to the register, by anyone at any level, is logged separately with the actor and the before and after values.
• Locked-down storage. The underlying records live on the Youth Protection SharePoint site, which general members cannot open.

The full detail of who sees what is on the Compliance Register guide.

Your part in keeping the system secure

Security is layered, and account holders are one of the layers. Three habits cover almost everything:

1. Keep your MFA method current. If you change phones, update your Authenticator before retiring the old one. See Changed or Lost Your Phone?.
2. Never share passwords or approve MFA prompts you did not trigger. An unexpected Authenticator prompt means someone else has your password: deny it and email support.
3. Report anything odd straight away. Suspicious emails, unexpected sign-in alerts, or files shared with the wrong people: send it to support@rotary9660.org.au. Early reports are the cheapest fixes.