Elementor #2415 – Kazumaconsulting

Xxx

FEE Project Test Report

MVP0 Tenant Lockdown

Test ID: FEE001

Author

Name:
Title:

Review and Approval/Signoff

I have reviewed this document and authorise it for issue:

Approved by	Role	Signature	Date
Rob Lai	Team Lead
Phil?	Project Manager
Tony?	Stakeholder
Kiran?	Stakeholder

Distribution List

Name	*Title*	*Business Unit*

Document Versions

Version	Date	Section	Nature of Amendment	Amendment Author
1.0	17/3/2010	All	Final

2.0 Introduction

Ensure clear audit trail, separation of duties, and measurable success criteria for testing the completion of MVP0.

Definition of “done” for MVP0 – new Azure tenant baseline build that includes all the features tenant lockdown.

Features are compliant with ASD recommendations.

2.1 Purpose

The purpose of this Test Report is to:

Define the scope of testing to be completed
Define roles and responsibilities
Document test risks, assumptions and constraints
Describe the types of testing to be done, including tools, environment, responsibilities and approach,
Describe the approach taken to defect management & defect metrics
Describe the test schedule milestones
Identify and describe each testing phase
Define entry and exit criteria of each test phase including test activities and validation tasks
Define the different test environment types

2.2 Scope

Features in scope for testing
Features out of scope
Testing types (Functional, Performance, Security, etc.)

In Scope

Tenant 100

Tenant 101… Tenant 105

Tenant lockdown features – endorsed by Cyber Team

Out of Scope

Tenant Build items features/capabilities exceeding lockdown

IaC codes,

2.3 Objectives & Success Criteria

All critical test cases executed
≤ X% high priority defects unresolved
All test evidence reviewed & signed off
Exit criteria met

Key Assumptions

3.0 Roles & Responsibilities

Role	Responsibilities	Person/Team
Test Designer	Creates test cases, test data	Jon Grech, Cloud Engineer, FEE Team
Tester	Executes test cases, logs results, marks Pass/Fail	Jon Grech, Cloud Engineer, FEE Team
Verifier	Independently reviews test evidence, confirms Pass/Fail, signs off	??, Cloud Engineer, FEE Team
Test Lead	Oversees process, ensures separation of duties	Francis??/ BA, FEE Team
Test Analyst	Provide Test Requirements, ensures QA of Test execution	Madhu??/BA, FEE Team
Development Team	Fixes defects, provides test environment	Cloud Engineers, FEE Team
Approver	Accepts test results, provides sign-off	Rob Lai/ Team Lead, FEE Team
Stakeholder	Accepts sign-off	Phil / Project Manager, FEE Team

4.0 Entry and Exit Criteria

Entry Criteria	Exit Criteria
· System Test Plan has been created, reviewed and approved · Test Cases have been created and reviewed · Test cases have been prioritised and ordered for execution · Test Data has been created · Environment request form has been delivered to Testing and QA and the booking confirmed. · Test environment has been built and basic testing has been performed to ensure environment is adequate · Xxx · Test people resources availability	All high and medium priority test cases have been executed and passed There are no Severity 1 and 2 defects outstanding Agreed resolution plan in place for outstanding severity 3 and 4 defects Xx All planned test cases executed and independently verified All critical/severe defects resolved Test summary report approved by stakeholders Pass rate ≥ 95% for high-priority test cases All verification sign-offs obtained

Entry Criteria

Exit Criteria

· System Test Plan has been created, reviewed and approved

· Test Cases have been created and reviewed

· Test cases have been prioritised and ordered for execution

· Test Data has been created

· Environment request form has been delivered to Testing and QA and the booking confirmed.

· Test environment has been built and basic testing has been performed to ensure environment is adequate

· Xxx

· Test people resources availability

All high and medium priority test cases have been executed and passed
There are no Severity 1 and 2 defects outstanding
Agreed resolution plan in place for outstanding severity 3 and 4 defects
Xx
All planned test cases executed and independently verified
All critical/severe defects resolved
Test summary report approved by stakeholders
Pass rate ≥ 95% for high-priority test cases
All verification sign-offs obtained

Environment

As there is no environment lifecycle implicit in the testing of Azure tenancy lockdown, the test environment will include all tenants, regardless of their purposed lifecycle:

Tenant	Purpose	Test Phase
FedGov100	Production	Phase 1
FedGov101	Non-Production	Phase 2
FedGov102	Production	Phase 3
FedGov103	TBD	Phase 4
FedGov104	TBD	Phase 5
FedGov105	TBD	Phase 6

Note: FedGov103-105 were purchased for future, yet to be determined purposes. However, the baseline tenant build features completed will still require tenant lockdown as a security measure. For security compliance reasons, these tenants will have to be tested for tenant lockdown.

Xxx Approach

Test Tools

Purpose	Tool
Defects Tracking	N/A
Test Assets Maintenance (eg: Test Cases, Test Scripts, Test Evidence)	Excel
Performance testing	N/A
Test Planning	Word, Excel
Progress Reporting	Excel
Traceability to User Stories/Requirements	Azure DevOps
Data validation	N/A
Test Automation	N/A

Test Data

Nil – not applicable to nature of tenant build unit testing.

Testing Schedule

An overview of the schedule for the test phases is shown in the following table. Detailed scheduling and task assignment are contained in the current project schedule.

Test Plan

Test Cases

Data Preparation

Execution

Raising Defects

Retestinf Defects

Closing Defects

Test Summary Report

Test Phase	Responsibility	Start	Finish
Phase 1
Produce Test Plan	Test Lead	xx/02/26	xx/02/26
Review Test Plan	Approver	xx/02/26	xx/02/26
Produce Test Cases	Test Designer	xx/02/26	xx/02/26
Produce User Stories/Requirements	Test Analyst
Review Test Cases	Test Analyst	xx/02/26	xx/02/26
Execute Test Cases	Tester/Verifier	xx/02/26	xx/02/26
Resolve Defects and Retest	Tester/Verifier	xx/02/26	xx/02/26
Review Test Results	Test Lead	xx/02/26	xx/02/26
Approve Test Report	Approver	xx/02/26	xx/02/26

5.1 Workflow

Test Execution
- Tester executes test case, records Actual Result
- Tester marks Pass/Fail based on comparison with Expected Result
- If Fail: logs defect, links to test case
Verification
- Reviewer (different person) examines:
  - Test steps followed correctly
  - Evidence (screenshots, logs)
  - Defect details (if failed)
- Reviewer confirms or disputes Pass/Fail judgment
- Reviewer signs off in “Verified By” column
Conflict Resolution
- If disagreement, Test Lead arbitrates
- May require re-testing or defect reassessment

5.2 Rules

Tester cannot verify their own execution
Reviewer must be independent (not involved in development of that feature)
Both signatures required for test case closure

Defect Management

A defect is identified whenever an expected post-condition of a test step or test scenario fails, does not happen or gives unexpected results. A defect can be raised against functional areas; for technical issues; for environment or for infrastructure build issues i.e. any event that prevents the successful execution of test cases.
A defect initially logged as a technical issue could be diagnosed during the defect resolution cycle as a functional defect in which case it would be assigned to the Requirements Manager (i.e. Functional Lead) for further investigation or resolution.
Defect severities differ depending on whether the system is in a test phase, or prior to implementation into production.
Reporting of defect priorities is also important. A severity of a particular defect may be low, but this may be blocking 50% of test cases from being executed. Therefore the priority of this defect will be High to ensure it is fixed quickly. The Defect management tool will be configured to ensure reporting of blocked test cases can occur.

10.0 Defect Severity and Priority

The following table describes these categories in terms of the 4 levels of defect severity that may apply:

Severity	Description
1 – Critical	The defect blocks functionality and/or data. It does not have a workaround and testing comes to a stop. This is considered the highest level priority defect and must be fixed immediately.
2 – Major	The defect affects critical functionality and/or data. It has a workaround but is not obvious and is difficult. This is considered a second highest level priority defect and must be fixed as soon as critical defects are fixed.
3 – Medium	The defect affects major functionality and/or non-critical data. It has an easy workaround. This is considered a medium level priority defect and must be fixed when all critical and high defects have been fixed and retested successfully.
4 – Minor	These defects do not affect functionality or data. They do not require a workaround and don’t impact productivity or efficiency. These are considered as cosmetic or ‘nice to have’ defects. They’re considered the lowest level priority defects and are fixed at the discretion of the project team/business unit.

The following Priority Levels are provided to determine the order by which bugs should be fixed for the same Severity.

Priority	Definition
1 – High	No further testing can be performed in this test cycle without the defect being resolved.
2 – Medium	Testing can proceed but prevents the solution from moving to the next phase without the defect being resolved, but will be resolved when time become available.
3 – Low	Testing can proceed, does not prevent the solution from moving to the next phase without the defect being resolved

5.3 Evaluation

All test cases have been successfully executed and no defects have been detected.

If any defects are encountered, then they need to be resolved, before the solution is be promoted to the next environment, including Production.

If the defects are vendor related and does not affect core functionality, then the business will need to provide approval to promote solution.

Xxx

Put in Roles and Responsibilities

6.0 Test Deliverables & Evidence

Deliverable	Description	Owner
Test Cases	Detailed test cases with steps	Test Designer
Test Execution Logs	Completed test case matrix	Tester
Defect Reports	Logged defects with severity	Tester
Verification Report	Summary of verified results	Reviewer
Test Summary Report	Overall test status, metrics	Test Lead

xxx

5.0 Pass/Fail Separation of Duties Process

7.0 Success Metrics & Reporting

7.1 Key Metrics

Test Coverage: % of requirements covered
Pass Rate: % of test cases passed
Defect Density: Defects per module/feature
Defect Resolution: % defects fixed/closed

7.2 Test Summary Report Content

Total test cases executed
Passed/Failed counts (verified)
Defect breakdown by severity
Open/closed defect status
Evidence of separation of duties (reviewer sign-offs)
Risks & issues
Recommendations for release

Appendix A Test Results

A.1 Phase 1 – FedGov100

Test Case ID	Test Scenario	Test Steps	Test Data	Expected Result	Actual Result	Pass/Fail (by Tester)	Verified By (Reviewer)	Comments/Defect ID
TC-001	User Login	1. Navigate to login page 2. Enter valid credentials 3. Click Submit	??	User is redirected to dashboard	[Filled during execution]	[Tester marks]	[Reviewer signs]	[If fail, link defect]
TC-002	Invalid login error	1. Enter invalid credentials 2. Click Submit	??	Error message appears	[Filled during execution]	[Tester marks]	[Reviewer signs]

A.2 Phase 1 – FedGov101

Test Case ID	Test Scenario	Test Steps	Test Data	Expected Result	Actual Result	Pass/Fail (by Tester)	Verified By (Reviewer)	Comments/Defect ID
TC-001	User Login	1. Navigate to login page 2. Enter valid credentials 3. Click Submit	??	User is redirected to dashboard	[Filled during execution]	[Tester marks]	[Reviewer signs]	[If fail, link defect]
TC-002	Invalid login error	1. Enter invalid credentials 2. Click Submit	??	Error message appears	[Filled during execution]	[Tester marks]	[Reviewer signs]

A.3 Phase 1 – FedGov102

A.4 Phase 1 – FedGov103

A.5 Phase 1 – FedGov104

A.6 Phase 1 – FedGov105

Appendix B Defects Analysis

B.1

Test Plan Template

1.0 Document Information

Item	Details
Project Name	[Project Name]
Test Plan ID	TP-[Project Code]-[Version]
Version	1.0
Date	[Date]
Author	[Name/Role]
Approvers	[QA Lead, Project Manager, etc.]

2.0 Introduction

2.1 Purpose

To define the scope, approach, resources, and schedule for testing activities, including roles and responsibilities for test execution and verification.

2.2 Scope

Features in scope for testing
Features out of scope
Testing types (Functional, Performance, Security, etc.)

2.3 Objectives & Success Criteria

All critical test cases executed
≤ X% high priority defects unresolved
All test evidence reviewed & signed off
Exit criteria met

3.0 Roles & Responsibilities Matrix

Role	Responsibilities	Person/Team
Test Designer	Creates test cases, test data	[Name/Team]
Tester (Executor)	Executes test cases, logs results, marks Pass/Fail	[Name/Team]
Verifier/Reviewer	Independently reviews test evidence, confirms Pass/Fail, signs off	[Name/Team]
Test Lead/Manager	Oversees process, ensures separation of duties	[Name]
Development Team	Fixes defects, provides test environment	[Dev Team]
Stakeholder	Accepts test results, provides UAT sign-off	[Product Owner/Client]

4.0 Test Cases Format & Examples

4.1 Test Case Template

Test Case ID	Test Scenario	Test Steps	Test Data	Expected Result	Actual Result	Pass/Fail (by Tester)	Verified By (Reviewer)	Comments/Defect ID
TC-001	User Login	1. Navigate to login page 2. Enter valid credentials 3. Click Submit	Username: user1 Password: Pass@123	User is redirected to dashboard	[Filled during execution]	[Tester marks]	[Reviewer signs]	[If fail, link defect]
TC-002	Invalid login error	1. Enter invalid credentials 2. Click Submit	Username: invalid Password: wrong	Error message appears	[Filled during execution]	[Tester marks]	[Reviewer signs]

5.0 Pass/Fail Separation of Duties Process

5.1 Workflow

Test Execution Phase
- Tester executes test case, records Actual Result
- Tester marks Pass/Fail based on comparison with Expected Result
- If Fail: logs defect, links to test case
Verification Phase
- Reviewer (different person) examines:
  - Test steps followed correctly
  - Evidence (screenshots, logs)
  - Defect details (if failed)
- Reviewer confirms or disputes Pass/Fail judgment
- Reviewer signs off in “Verified By” column
Conflict Resolution
- If disagreement, Test Lead arbitrates
- May require re-testing or defect reassessment

5.2 Rules

Tester cannot verify their own execution
Reviewer must be independent (not involved in development of that feature)
Both signatures required for test case closure

6.0 Test Deliverables & Evidence

Deliverable	Description	Owner
Test Cases	Detailed test cases with steps	Test Designer
Test Execution Logs	Completed test case matrix	Tester
Defect Reports	Logged defects with severity	Tester
Verification Report	Summary of verified results	Reviewer
Test Summary Report	Overall test status, metrics	Test Lead

7.0 Success Metrics & Reporting

7.1 Key Metrics

Test Coverage: % of requirements covered
Pass Rate: % of test cases passed
Defect Density: Defects per module/feature
Defect Resolution: % defects fixed/closed

7.2 Test Summary Report Content

Total test cases executed
Passed/Failed counts (verified)
Defect breakdown by severity
Open/closed defect status
Evidence of separation of duties (reviewer sign-offs)
Risks & issues
Recommendations for release

8.0 Exit Criteria

Testing is complete when:

All planned test cases executed and independently verified
All critical/severe defects resolved
Test summary report approved by stakeholders
Pass rate ≥ 95% for high-priority test cases
All verification sign-offs obtained

9.0 Approvals

Role	Name	Signature	Date
Test Lead
Project Manager
Quality Assurance Head

Note: This template ensures clear audit trail, separation of duties, and measurable success criteria for testing projects.

what are the australian asd recommendations for locking down a new Azure tenant

Excellent question. Locking down a new Azure tenant according to the Australian Signals Directorate (ASD)’s Essential Eight (E8) maturity model is a critical first step for any Australian organisation. The ASD does not have a single, prescriptive “Azure tenant lockdown guide,” but their Essential Eight strategies and supporting guidance (like the Cloud Security Guidance) provide the absolute baseline.

Here are the key ASD-aligned recommendations for locking down a new Azure tenant, structured as a phased approach.

Core Philosophy: Assume Breach & Least Privilege

Apply the principles of Zero Trust: explicitly verify, grant least privilege access, and assume a breach will occur.

Phase 1: Foundational Identity & Access Security (E8 Focus)

This is the absolute priority, aligning with the Essential Eight’s focus on restricting administrative privileges and multi-factor authentication.

Break Glass Emergency Accounts:
- Create a minimum of 2-3 global administrator accounts that are:
  - Cloud-only (not synced from on-premises).
  - Protected with MFA using the strongest method (hardware token or Microsoft Authenticator number matching).
  - Have long, complex passwords (20+ characters) stored in a secure physical location (e.g., safe).
  - Have no MFA exemptions and are not used for daily operations.
Eradicate Standing Privilege for Admins:
- Do NOT assign the Global Administrator role to any daily-use user account.
- Implement Privileged Identity Management (PIM) for Just-In-Time (JIT) access.
- Require MFA, strong authentication, and a business justification for activating any privileged role (Global Admin, Exchange Admin, Security Admin, etc.).
- Set maximum activation periods (e.g., 8 hours).
Enforce Multi-Factor Authentication (MFA) – ALF:
- Enable MFA for ALL users, without exception. This is a core ASD requirement.
- Move away from SMS/phone call methods. Enforce stronger methods:
  - Microsoft Authenticator app (number matching).
  - FIDO2 security keys (highest security).
- Use Conditional Access policies to enforce this. Do not rely on the legacy “per-user MFA” settings.
Conditional Access Policies (The Core Control Plane):
- Create policies to:
  - Block legacy authentication (POP3, IMAP, SMTP, etc.) for all users.
  - Require MFA for all administrative portals (Azure, Azure DevOps, Microsoft 365).
  - Require MFA from untrusted locations (anywhere except defined corporate networks).
  - Require compliant or Hybrid Azure AD joined devices for accessing sensitive data or services.

Phase 2: Tenant-Wide Configuration & Governance

Manage Tenant Creation & Ownership:
- Use the Microsoft Partner Center if a partner helped create the tenant, to establish proper governance.
- Verify and secure the initial global administrator accounts.
Azure AD Device Management:
- Implement Hybrid Azure AD Join (if you have on-prem AD) or Azure AD Join for cloud-native devices.
- Enforce device compliance policies (disk encryption, firewall, no jailbreak).
Secure External Identities:
- Review and disable outdated external collaboration settings in Azure AD External Identities.
- Set guidelines for Azure AD B2B collaboration. Consider using Entitlement Management for granular, time-bound external access.
Disable Deprecated Protocols & Consent:
- Disable user consent for OAuth applications. Instead, require admin consent after security review.
- Audit and restrict Service Principals and Managed Identities.

Phase 3: Logging, Monitoring, and Microsoft 365 Baseline

Enable Unified Auditing:
- Turn on Microsoft Purview Audit (Standard or Premium) to capture logs for all services. This is critical for detection and investigation (another E8 requirement).
Configure Microsoft Defender for Cloud & Microsoft 365 Defender:
- Enable Microsoft Defender for Cloud (with enhanced security features) on the subscription level. Apply secure score recommendations.
- Enable Microsoft Defender for Identity if using Hybrid AD.
- Integrate signals into a Security Information and Event Management (SIEM) system, as per ASD’s centralised logging recommendations.
Apply Microsoft 365 Security Baselines:
- In the Microsoft 365 Defender portal, use the “Score” and “Baselines” sections to apply Microsoft’s recommended security configurations for all workloads (Exchange Online, SharePoint, Teams, etc.).

Phase 4: Subscription & Resource Organization

Management Group & Subscription Structure:
- Design a hierarchy using Management Groups (e.g., Production, Non-Production, Sandbox).
- Use separate subscriptions for different workloads/environments to provide scope boundaries for policies and roles.
Azure Policy & Blueprints:
- Immediately assign the “Azure Security Benchmark” initiative to all subscriptions via Azure Policy.
- Create and assign policies to enforce:
  - Allowed resource locations (Australia East/Central regions).
  - Required tags (Cost Centre, Environment, Data Classification).
  - Enforcement of specific SKUs or resource types.

Key ASD & Australian Government Specific References

ASD Essential Eight: The core framework. Maturity Level 2 or 3 should be your target for a new tenant.
- https://www.cyber.gov.au/acsc/view-all-content/essential-eight
ASD Cloud Security Guidance: Provides cloud-specific context for implementing the Essential Eight.
- https://www.cyber.gov.au/acsc/view-all-content/guidance/cloud-security-guidance
Microsoft Blueprint for ASD Essential Eight: This is your most practical starting point.
- Microsoft has published an ASD Essential Eight Blueprint in the Azure Portal. Go to Blueprint assignments > Create > Browse gallery and search for “ASD”. This deploys and assigns a set of policies and templates that align with the framework.
Information Security Manual (ISM): The overarching controls framework. Pay attention to controls for cloud services.
- https://www.cyber.gov.au/acsc/view-all-content/ism
Microsoft’s Azure Security Benchmark: Maps directly to global and regional standards, including the ISM.

Recommended First Step: After creating your break-glass accounts, immediately go to the Azure Portal and deploy the “Microsoft cloud security benchmark” and the “ASD Essential Eight” blueprint to your root management group or primary subscription. This will automatically configure hundreds of security settings in alignment with ASD’s advice.

please list the test cases with references to the above recommendations to achieve compliant tenant lockdown

Australian ASD-Compliant Azure Tenant Lockdown Test Cases

Based on the ASD Essential Eight and cloud security recommendations, here are comprehensive test cases to validate your tenant lockdown.

Category 1: Identity & Access Management (Essential Eight Alignment)

TC-01: Break Glass Emergency Accounts

Test Case ID	TC-01-01
Description	Verify break glass emergency accounts are properly configured
Test Steps	1. List all users with Global Administrator role 2. Check if 2-3 dedicated break glass accounts exist 3. Verify accounts are cloud-only (not synced) 4. Check MFA registration status 5. Verify no Conditional Access exemptions
Expected Result	– 2-3 dedicated accounts with naming convention (e.g., emerg-admin-01) – Accounts show as “Cloud” in onPremisesSyncEnabled property – MFA registered with strong methods – No daily user accounts have permanent Global Admin
ASD Reference	Essential Eight: Restrict Administrative Privileges (ML1, ML2, ML3)
Azure Check	Get-MgUser -Filter “userPrincipalName eq ’emerg-admin-01@tenant.onmicrosoft.com'” Get-MgUser -All \| Where-Object {$_.onPremisesSyncEnabled -eq $true} \| Select displayName

TC-02: Privileged Identity Management (PIM) Implementation

Test Case ID	TC-02-01
Description	Verify PIM is configured for all privileged roles
Test Steps	1. Check if PIM is enabled for the tenant 2. Verify Global Administrator role requires activation 3. Check activation requires MFA and justification 4. Verify maximum activation duration ≤ 8 hours 5. Check approval workflows for critical roles
Expected Result	– PIM shows “Configured” status – Global Admin role has activation requirement – MFA enforced during activation – Business justification mandatory – Maximum duration 8 hours or less
ASD Reference	Essential Eight: Restrict Administrative Privileges (ML2, ML3)
Azure Check	Navigate to Azure AD → Privileged Identity Management → Azure AD roles

TC-03: Multi-Factor Authentication Enforcement

Test Case ID	TC-03-01
Description	Verify MFA is enforced for all users via Conditional Access
Test Steps	1. Review Conditional Access policies 2. Check for “Require MFA for all users” policy 3. Verify policy applies to “All cloud apps” 4. Check exclusions (if any) 5. Verify legacy authentication is blocked
Expected Result	– CA policy named “MFA-ALL-USERS-01” exists – Policy applies to all users (no exclusions) – Legacy auth blocked by separate policy – Grant controls require MFA
ASD Reference	Essential Eight: Multi-factor Authentication (ML1, ML2, ML3)
Azure Check	Get-MgIdentityConditionalAccessPolicy or Azure Portal → Security → Conditional Access

TC-04: Administrative Portal Access Controls

Test Case ID	TC-04-01
Description	Verify additional controls for administrative portals
Test Steps	1. Check for CA policy targeting admin portals 2. Verify requires compliant device 3. Check location restrictions (Australia-only if required) 4. Verify risk-based policies
Expected Result	– Separate policy for “Microsoft Azure Management” – Requires device compliance or hybrid Azure AD join – May require specific locations for high-privilege access
ASD Reference	ASD Cloud Security Guidance: Section 4.2
Azure Check	Azure Portal → Conditional Access → Policies targeting “Microsoft Azure Management”

Category 2: Device & Session Security

TC-05: Device Compliance Enforcement

Test Case ID	TC-05-01
Description	Verify device compliance policies are configured
Test Steps	1. Check Intune device compliance policies 2. Verify encryption requirement (BitLocker) 3. Check firewall requirement (enabled) 4. Verify antivirus/EDR requirement 5. Test device compliance reporting
Expected Result	– Compliance policies exist for each platform (Windows, macOS, iOS, Android) – Encryption required for Windows devices – Microsoft Defender Antivirus or equivalent required
ASD Reference	Essential Eight: Patch Applications, Patch Operating Systems
Azure Check	Endpoint Manager → Devices → Compliance policies

TC-06: Session Management Controls

Test Case ID	TC-06-01
Description	Verify session timeout and idle controls
Test Steps	1. Check Azure AD sign-in frequency policies 2. Verify browser session persistence settings 3. Check Conditional Access session controls 4. Verify admin session timeouts
Expected Result	– Sign-in frequency ≤ 8 hours for users – Admin sessions timeout ≤ 1 hour – Browser sessions don’t persist indefinitely
ASD Reference	ISM Control: 1513 – Session management
Azure Check	Conditional Access → Policy → Session controls

Category 3: Application & Data Security

TC-07: Application Consent Framework

Test Case ID	TC-07-01
Description	Verify user consent for applications is disabled
Test Steps	1. Check Azure AD → Enterprise applications → Consent and permissions 2. Verify “User consent for apps” is set to “Do not allow” 3. Check admin consent workflow 4. Review existing consented applications
Expected Result	– User consent disabled – Admin consent workflow enabled (optional) – Regular review process for consented apps
ASD Reference	ASD Cloud Security Guidance: Section 4.6
Azure Check	Azure AD → Enterprise applications → Consent and permissions

TC-08: Microsoft 365 Baseline Configurations

Test Case ID	TC-08-01
Description	Verify M365 security baselines are applied
Test Steps	1. Check Microsoft 365 Defender portal → Secure Score 2. Verify security baselines applied 3. Check Exchange Online protections 4. Verify SharePoint/OneDrive restrictions 5. Check Teams meeting policies
Expected Result	– Secure Score > 80% – Exchange safe attachments enabled – SharePoint external sharing restricted – Anonymous meeting join disabled
ASD Reference	Microsoft Security Baseline for M365
Azure Check	security.microsoft.com → Secure Score → Improvement actions

Category 4: Logging, Monitoring & Detection

TC-09: Unified Audit Logging

Test Case ID	TC-09-01
Description	Verify audit logging is enabled and retained
Test Steps	1. Check Purview Audit configuration 2. Verify retention period ≥ 12 months (ML3) 3. Test search functionality 4. Check critical events are captured 5. Verify no disabled audit activities
Expected Result	– Audit log search returns results – Retention ≥ 12 months – Administrative activities logged – No audit activities disabled
ASD Reference	Essential Eight: Regular backups (extended to logs)
Azure Check	compliance.microsoft.com → Audit → Audit retention policies

TC-10: Defender for Cloud Configuration

Test Case ID	TC-10-01
Description	Verify Microsoft Defender for Cloud is properly configured
Test Steps	1. Check Defender plans are enabled 2. Verify auto-provisioning of agents 3. Check secure score configuration 4. Verify regulatory compliance dashboard 5. Check alert configuration
Expected Result	– Defender for Servers, SQL, Storage enabled – Auto-provisioning enabled – Azure Security Benchmark assigned – Alerts sent to security team
ASD Reference	Essential Eight: Application Control, Patch Applications
Azure Check	Azure Portal → Microsoft Defender for Cloud → Environment settings

Category 5: Governance & Policy

TC-11: Azure Policy Compliance

Test Case ID	TC-11-01
Description	Verify ASD Essential Eight Blueprint is assigned
Test Steps	1. Check Blueprint assignments 2. Verify ASD Essential Eight Blueprint deployed 3. Check policy compliance state 4. Review non-compliant resources 5. Verify remediation tasks
Expected Result	– ASD Essential Eight Blueprint assigned – Compliance state > 90% – Remediation tasks configured for non-compliant resources
ASD Reference	ASD Essential Eight Blueprint
Azure Check	Azure Portal → Blueprints → Assigned blueprints

TC-12: Resource Location Restrictions

Test Case ID	TC-12-01
Description	Verify resources are created only in approved regions
Test Steps	1. Check “Allowed locations” Azure Policy 2. Verify only Australian regions allowed 3. Test creating resource in blocked region 4. Check existing resource locations 5. Verify policy enforcement mode
Expected Result	– Policy denies creation in non-AU regions – Only “australiaeast” and “australiasoutheast” allowed – Policy enforcement mode is “Deny”
ASD Reference	ISM Control: 1648 – Data location
Azure Check	Azure Policy → Assignments → “Allowed locations” policy

Category 6: Network Security

TC-13: External Collaboration Controls

Test Case ID	TC-13-01
Description	Verify external sharing controls are configured
Test Steps	1. Check Azure AD External Identities settings 2. Verify B2B collaboration limits 3. Check SharePoint external sharing settings 4. Verify Teams guest access controls 5. Review Entitlement Management catalogs
Expected Result	– B2B collaboration limited to specific domains – SharePoint external sharing restricted – Teams guest access requires approval – Access packages with expiration dates
ASD Reference	ASD Cloud Security Guidance: Section 4.7
Azure Check	Azure AD → External Identities → External collaboration settings

Category 7: Backup & Recovery

TC-14: Backup Verification

Test Case ID	TC-14-01
Description	Verify critical data backup configuration
Test Steps	1. Check Azure Backup vault configuration 2. Verify retention policies (≥ 3 months for ML2) 3. Test restore procedure 4. Check backup health status 5. Verify geo-redundant storage
Expected Result	– Backup vault exists and is configured – Retention ≥ 3 months for files/systems – Test restore successful – Backup jobs show “Completed” status
ASD Reference	Essential Eight: Regular backups (ML2, ML3)
Azure Check	Azure Portal → Backup vaults → Backup instances

Testing Framework & Reporting

TC-15: Compliance Assessment

Test Case ID	TC-15-01
Description	Generate comprehensive compliance report
Test Steps	1. Run Microsoft Compliance Score assessment 2. Generate Azure Security Benchmark report 3. Map controls to ASD Essential Eight 4. Document gaps and remediation plan 5. Schedule retest frequency
Expected Result	– Compliance score report generated – Gaps documented with remediation timeline – Regular assessment scheduled (quarterly) – Executive summary for management
ASD Reference	All ASD references above
Azure Check	compliance.microsoft.com → Compliance Manager → Assessments

Testing Methodology

Pre-requisites:
- Test accounts with varying privilege levels
- Audit and Security Reader roles for testers
- Test subscription in isolated management group
- Approval for penetration testing activities
Testing Frequency:
- Initial: Comprehensive test after tenant creation
- Monthly: Critical controls (TC-01 to TC-04)
- Quarterly: Full test suite
- After Changes: Relevant test cases post-modification
Evidence Collection:
- Screenshots of configurations
- PowerShell output with timestamps
- Compliance score reports
- Policy compliance states
Remediation Tracking:
- Risk register for non-compliant items
- Remediation deadlines (Critical: 7 days, High: 30 days)
- Re-test verification process

This test framework provides traceability to ASD requirements while being practical for implementation. Regular execution ensures ongoing compliance with Australian government security standards.

xxx