AI-Powered Security Assessment

Answer scenario-based questions to discover which compliance frameworks your organisation needs, identify critical gaps, and get a prioritised roadmap — completely free.

18
Questions
7
Phases
20+
Frameworks
5 min
To Complete
Phase 1: Regulatory Context
1 of 30
Where is your organisation primarily based?
Your jurisdiction determines which regulatory frameworks are mandatory vs. voluntary.
Australia
Subject to Privacy Act, APRA (if financial), SOCI Act (if critical infra), ASD Essential Eight
New Zealand
Subject to NZ Privacy Act 2020, NZISM, CERT NZ guidance
United States
Subject to NIST frameworks, state privacy laws, sector-specific (HIPAA, SOX, GLBA)
EU / UK
Subject to GDPR, NIS2 Directive, Cyber Resilience Act, UK Cyber Essentials
Asia-Pacific (Other)
Singapore (PDPA/MAS TRM), India (DPDP Act), Japan (APPI), regional frameworks
Multi-jurisdictional
Operating across multiple countries — need to comply with overlapping regulations
Phase 1: Regulatory Context
2 of 30
Which industry best describes your organisation?
Why this matters: Different industries have sector-specific regulations that mandate certain security frameworks. A hospital must comply with health data laws, while a bank faces prudential standards — choosing the wrong framework wastes time and budget.
Government / Defence / Public Sector
Handles classified or sensitive government data, contracts with defence
Financial Services / Banking / Insurance
APRA-regulated, processes financial transactions, fiduciary obligations
Healthcare / Pharmaceutical / Life Sciences
Handles patient records, clinical data, health identifiers
Technology / SaaS / Cloud Services
Provides services to other businesses, handles customer data
Energy / Utilities / Critical Infrastructure
Operates essential services, SCADA/OT environments, public safety
Retail / E-Commerce / Hospitality
Processes consumer transactions, loyalty programs, POS systems
Education / Research
Student records, research data, institutional governance
Professional Services / Other
Legal, consulting, manufacturing, logistics, media
Phase 1: Regulatory Context
3 of 30
Does your organisation handle government data or hold government contracts?
Scenario: Your company wins a contract to build software for a federal agency. The contract requires you to handle PROTECTED-level data. You now need an IRAP assessment at PROTECTED level before you can access any government systems. Without it, the contract cannot proceed.
Yes — PROTECTED or above
We handle classified or PROTECTED government data (requires IRAP assessment)
Yes — OFFICIAL:Sensitive or below
We handle OFFICIAL or OFFICIAL:Sensitive data (ISM controls apply)
Government contractor (no classified data)
We supply services to government but don’t directly handle classified data
No government involvement
We don’t hold government contracts or handle government data
Phase 1: Regulatory Context
4 of 30
What types of sensitive data does your organisation process?
Select ALL that apply. Each data type triggers specific regulatory requirements.
Personal Identifiable Information (PII)
Names, addresses, emails, phone numbers, dates of birth
Financial / Payment Card Data
Credit card numbers, bank accounts, transaction records
Health / Medical Records
Patient records, clinical data, health identifiers, Medicare numbers
Authentication Credentials / Secrets
Passwords, API keys, certificates, MFA seeds, tokens
Intellectual Property / Trade Secrets
Source code, algorithms, product designs, research data
EU Resident Data
Any personal data of individuals in the EU/EEA (triggers GDPR)
Select all that apply
Phase 1: Data Privacy & Consent
5 of 30
How does your organisation manage data privacy obligations?
Scenario: A customer exercises their “right to be forgotten” under GDPR. Your team needs to locate every system that holds this person’s data, verify deletion, and provide evidence within 30 days. Without a privacy governance framework, this becomes a panicked, manual scramble across 20 systems — with no audit trail proving you complied.
No formal privacy programme
No privacy officer, no data mapping, reactive approach to requests
Basic privacy policy exists but limited operationalisation
Privacy policy on website, but no ROPA, no DSAR process, no consent tracking
Some privacy controls in place
Have a privacy officer, basic data mapping, but manual DSAR handling
Mature privacy programme
Automated DSARs, ROPA maintained, consent management, breach response plan, DPIAs conducted
Phase 1: Data Privacy & Consent
6 of 30
How do you manage user consent for data collection and processing?
Scenario: Your marketing team wants to email 50,000 customers about a new product. Legal asks: “Can you prove each person consented to marketing communications? Can you show when they consented, what they consented to, and whether any have withdrawn?” If your answer involves a spreadsheet, you have a consent management gap.
No formal consent tracking
No record of when/how consent was obtained, no withdrawal mechanism
Basic opt-in checkboxes on forms
Checkboxes exist but no centralised consent registry, no granular purposes
Cookie consent platform + email preferences
CMP for cookies, email unsubscribe, but no unified consent record
Centralised consent management with audit trail
Purpose-based consent, withdrawal support, consent receipts, legal basis documented
Phase 1: Data Privacy & Consent
7 of 30
Does your organisation transfer personal data across national borders?
Scenario: Your Australian company uses AWS US-East for hosting, Google Workspace (US-based), and a Philippines-based BPO for customer support. Under the Australian Privacy Act APP 8, you must ensure overseas recipients comply with the APPs. Under GDPR, transfers outside the EU require Standard Contractual Clauses. Violations carry fines up to 4% of global turnover.
All data stays in-country
Hosting, processing, and support all within our jurisdiction
Cloud services in other countries (SaaS, IaaS)
Using US/EU cloud providers but no formal transfer assessment done
Active cross-border transfers (BPO, offshore teams, global customers)
Data flows across multiple jurisdictions for business operations
Cross-border transfers with SCCs / adequacy agreements in place
Transfer Impact Assessments done, contractual safeguards documented
Phase 2: Threat & Risk Landscape
8 of 30
How many employees and managed identities does your organisation have?
Why this matters: An organisation with 50 employees managing 200 cloud accounts has fundamentally different identity governance needs than one with 20,000 employees across 15 countries. The scale determines whether manual processes will work or if you need automated lifecycle management.
Under 50 employees
Startup or small business. Identity management likely manual or ad-hoc.
50 – 500 employees
Growing team. Starting to feel pain of manual onboarding/offboarding.
500 – 5,000 employees
Mid-market. Multiple departments, locations, compliance requirements.
5,000+ employees
Enterprise. Complex org structure, multiple business units, global operations.
Phase 2: Threat & Risk Landscape
9 of 30
Has your organisation experienced a security incident in the last 24 months?
Scenario: After a phishing attack compromised an executive’s email, the attacker used their credentials to access the finance system and initiate fraudulent wire transfers. The board now demands a full security assessment and evidence that controls are in place to prevent recurrence.
Yes — significant breach (data loss, financial impact, regulatory notification)
Required to notify authorities, customers, or regulators
Yes — minor incident (contained, no external impact)
Phishing attempt caught, malware quarantined, near-miss events
Not sure — we don’t have good visibility
No formal incident tracking or SIEM in place
No known incidents
Clean record or unaware of any compromises
Phase 2: Threat & Risk Landscape
10 of 30
Do your clients or partners require you to demonstrate compliance?
Scenario: A Fortune 500 prospect sends you a vendor security questionnaire. They require a SOC 2 Type II report before they’ll sign the contract. Your competitor already has one. Without it, you lose the deal worth $2M annually.
Yes — clients ask for SOC 2 / audit reports
Prospects require third-party attestation before purchasing
Yes — clients require ISO 27001 certification
RFPs or contracts mandate ISO 27001 ISMS certification
Yes — we receive security questionnaires frequently
Ad-hoc vendor assessments but no formal certification required yet
Not currently — but anticipating it
Planning to pursue enterprise clients who will require compliance evidence
Phase 2: Threat & Risk Landscape
11 of 30
How many third-party SaaS applications and vendors have access to your data?
Why this matters: The MOVEit breach (2023) and Optus breach (2022) demonstrated how third-party supply chain risk can be catastrophic. Each vendor with access to your data is a potential attack vector that needs governance.
Under 10 vendors
Minimal SaaS footprint, mostly in-house
10 – 50 vendors
Growing SaaS adoption, some vendor management in place
50+ vendors
Extensive SaaS ecosystem, potential shadow IT, supply chain complexity
Phase 3: Current Security Posture
12 of 30
How do you currently manage user access and identity lifecycle?
Scenario: An employee resigned last Friday. On Monday, their Active Directory account is still active, their Jira access is unchanged, and their GitHub repos still have their SSH keys. HR sent an email to IT, but nobody actioned it yet. Sound familiar?
Spreadsheets / email requests / manual processes
No centralised IAM. Access requests via email, tickets, or verbal
Basic directory (AD / Entra ID / Google Workspace only)
Central directory for auth but no governance, no lifecycle automation
Multiple point solutions (some SSO, some PAM, no unified view)
Fragmented tools, no single pane of glass for identity governance
Enterprise IGA platform with automated lifecycle
Centralised governance, automated JML, access reviews, SoD
Phase 3: Current Security Posture
13 of 30
What is your infrastructure and cloud environment?
This determines your attack surface and which cloud security frameworks apply.
Predominantly on-premise
Physical data centres, on-prem AD, limited cloud adoption
Hybrid (on-premise + cloud)
Mix of on-prem and cloud workloads, hybrid identity (AD + Entra ID)
Cloud-first / Cloud-native
Primarily cloud workloads (AWS, Azure, GCP), cloud-native identity
Multi-cloud
Workloads across 2+ cloud providers, complex identity federation
Phase 3: Current Security Posture
14 of 30
Which security controls do you currently have in place?
Select ALL that apply. This helps us identify gaps against recommended frameworks.
Multi-Factor Authentication (MFA) enforced
Single Sign-On (SSO) for applications
Privileged Access Management (PAM)
SIEM / Security monitoring
Regular backups with tested recovery
Automated patch management
Documented Incident Response Plan
None of the above
Select all that apply
Phase 3: Current Security Posture
15 of 30
What keeps you up at night? Select your top identity security concern.
Scenario: Your CISO presents to the board. The first question is: “Can you tell me exactly who has access to our crown jewels right now?” If you can’t answer confidently in under 60 seconds, you have an identity governance problem.
No visibility into who has access to what
Can’t produce an access report for auditors on demand
Orphan accounts and access creep
Former employees still have active accounts, permissions accumulate
Joiner/Mover/Leaver is a nightmare
Onboarding takes days, offboarding is inconsistent, role changes are missed
Failing audits or can’t prove compliance
Auditors raise findings, evidence is scattered, manual collection takes weeks
Privileged access is ungoverned
Shared admin accounts, no session recording, no just-in-time access
Segregation of Duties violations
Same person can approve and execute payments, no conflict detection
Phase 4: Readiness & Priorities
16 of 30
Are any of these sector-specific regulations applicable to you?
Select ALL that apply. These trigger mandatory framework requirements.
CPS 234 (APRA-regulated entity)
Banks, insurers, super funds regulated by APRA
SOCI Act (Critical Infrastructure)
Energy, water, transport, health, communications, financial markets, data
PCI DSS (Payment Card Processing)
Process, store, or transmit credit card data
HIPAA (US Healthcare)
Handle Protected Health Information (PHI) in the US
None of these apply
Select all that apply
Phase 4: Readiness & Priorities
17 of 30
What is your approximate annual budget for security and compliance tooling?
Context: The average mid-market Australian company spends 5–8% of IT budget on cybersecurity. Legacy IGA platforms (e.g., on-premise solutions) typically cost A$80K–250K/year. Activitee delivers equivalent capability from A$8K/year.
No dedicated budget yet
Need to build a business case for investment
Under A$10,000 / year
Looking for affordable, high-value solutions
A$10,000 – A$50,000 / year
Ready to invest in proper governance tooling
A$50,000+ / year
Enterprise-grade budget for comprehensive security program
Phase 4: Readiness & Priorities
18 of 30
What is driving the urgency for this assessment?
Understanding your timeline helps us prioritise recommendations.
Post-incident response — need to demonstrate remediation
Board/regulator requiring evidence of security improvements
Upcoming audit or certification deadline
Assessment due within 1–3 months
Client or prospect requirement
Need compliance evidence to close a deal or retain a customer
Proactive — building a security program
No immediate deadline, planning for long-term security maturity
Just exploring options
Early-stage research, gathering information
Phase 5: AI Governance
19 of 30
Does your organisation develop, deploy, or use AI/ML systems?
AI governance requirements are expanding rapidly. The EU AI Act, NIST AI RMF, and ISO 42001 all impose obligations on AI system operators.
We develop AI/ML models (internal or customer-facing)
Training models, fine-tuning LLMs, building ML pipelines, deploying AI features
We integrate third-party AI (GPT, Copilot, Gemini, etc.)
Using AI APIs, embedding AI features, AI-powered SaaS tools in workflows
Exploring / piloting AI adoption
POCs, evaluating AI tools, employees using ChatGPT/Copilot informally
No AI usage currently
Not currently using, developing, or planning AI adoption
Phase 5: AI Governance
20 of 30
What AI governance controls do you have in place?
Select all that apply. These map to ISO 42001, NIST AI RMF, and EU AI Act requirements.
AI Acceptable Use Policy
Documented policy governing how employees and systems use AI tools
AI System Inventory / Registry
Catalogue of all AI/ML models, their risk classification, and business owners
AI Risk Assessment Process
Formal risk assessment for AI systems covering bias, fairness, safety, privacy
AI Model Monitoring & Drift Detection
Continuous monitoring of AI model performance, data drift, and output quality
AI Data Governance (training data, PII handling)
Controls over data used to train/fine-tune models, PII redaction, data provenance
No AI-specific governance controls
No formal policies, inventories, or risk assessments for AI systems
Phase 5: AI Governance
21 of 30
What is the risk profile of your AI systems?
The EU AI Act classifies AI systems by risk level. Higher-risk systems face stricter obligations.
High-risk — decisions affecting people (hiring, credit, medical, legal)
AI that makes or significantly influences decisions about individuals. EU AI Act Annex III.
Limited-risk — customer-facing chatbots, content generation
AI that interacts with users, generates content, or processes personal data. Transparency obligations apply.
Minimal-risk — internal analytics, spam filters, recommendations
AI used for internal operations, no decisions affecting individuals. Lowest regulatory burden.
Not sure — haven’t classified our AI systems by risk
No formal AI risk classification process in place
Phase 5: AI Governance
22 of 30
How do you manage AI-related identity and access security?
AI systems introduce unique IAM challenges: service accounts, API keys, model access, and automated decision-making authority.
AI service accounts governed — RBAP, key rotation, audit trails
AI system credentials managed through IAM, with role-based access, regular key rotation, and full audit logging
Some controls — API keys managed but no formal governance
API keys stored in vault or env vars, some access logging, but no formal AI credential lifecycle
No AI-specific access controls — shared credentials, no audit
AI systems use shared API keys, hardcoded credentials, no logging of AI-initiated actions
Not applicable — no AI systems
No AI systems requiring access governance
Phase 6: Infrastructure & Operations
23 of 30
Does your organisation operate, own, or host services in data centres?
Why this matters: Data centre operators face specific compliance requirements for physical infrastructure, power resilience, cooling, and physical security that go beyond standard cybersecurity frameworks.
We operate our own data centre(s)
We own/lease and manage physical DC facilities with our own power, cooling, and physical security
We use colocation / hosted facilities
Our equipment is in a 3rd party DC (Equinix, Macquarie DC, NextDC, etc.) — we don't manage the facility
We are a DC / cloud service provider
We provide DC hosting, colocation, or cloud services to other organisations
We host Australian Government workloads
Our DC hosts or plans to host Australian Government data (requires HCF certification)
Cloud-only / no physical DC involvement
We use AWS, Azure, GCP, or SaaS — no physical data centre operations
Phase 6: Infrastructure & Operations
24 of 30
What availability and resilience level does your infrastructure require?
Context: Uptime Institute Tier III (99.982%) allows concurrent maintenance without downtime. Tier IV (99.995%) is fault-tolerant — any single failure has zero impact. Most enterprise workloads need Tier III; financial and government need Tier IV.
Basic availability (Tier I/II)
Non-critical workloads, dev/test environments, cost-optimised. Some planned downtime acceptable.
High availability (Tier III)
Production workloads, customer-facing services. Concurrent maintainability required — no planned downtime.
Mission-critical / fault tolerant (Tier IV)
Financial systems, government PROTECTED+, healthcare. Zero downtime — any single fault has no impact.
Not applicable (cloud-only)
We rely on cloud provider SLAs — no physical infrastructure to classify
Phase 6: Infrastructure & Operations
25 of 30
Does your organisation operate critical infrastructure or industrial control systems?
Context: Under Australia's SOCI Act 2018, critical infrastructure spans 11 sectors including data storage/processing, telecommunications, energy, water, healthcare, and financial services. SOCI-regulated entities must implement a Critical Infrastructure Risk Management Program (CIRMP).
SOCI Act regulated
We are classified as critical infrastructure under Australia's SOCI Act 2018
OT / ICS / SCADA systems
We operate industrial control systems, SCADA, PLCs, or operational technology
Energy / grid connected
Our DC connects to the national electricity grid or we generate/distribute energy
Telecommunications carrier
We provide telecommunications or internet services
None of the above
We don't operate critical infrastructure or industrial systems
Select all that apply
Phase 6: Infrastructure & Operations
26 of 30
Does your organisation have energy efficiency or sustainability reporting obligations?
Select ALL that apply. These determine whether energy and environmental frameworks are recommended.
NABERS rated / seeking rating
We have or need a NABERS Energy rating for our data centre (mandatory for AU Gov DC providers)
NGER Scheme reporting
We report under the National Greenhouse and Energy Reporting Scheme
ESG / climate disclosure
We report ESG metrics, Scope 1/2/3 emissions, or prepare AASB S2 sustainability reports
Green certification target
We target green building/DC certification (Green Star, SS 564, EU Energy Taxonomy)
No sustainability obligations
We don't have specific energy or sustainability reporting requirements
Select all that apply
Phase 7: DC Governance & Data Sovereignty
27 of 30
What physical security and environmental controls does your data centre have?
Why this matters: TIA-942, EN 50600, and Uptime Institute standards mandate specific physical security (mantrap, biometrics, CCTV) and environmental controls (HVAC redundancy, fire suppression, flood protection). These are auditable and affect your tier classification.
Enterprise-grade (TIA-942 / EN 50600 compliant)
Biometric + PIN access, mantrap, 24/7 NOC, CCTV 90-day retention, N+1 HVAC, gas fire suppression, seismic bracing
Managed colo provides these controls
Our colo provider (Equinix, NextDC, etc.) manages physical security. We have SLAs but don't operate controls directly
Basic controls (card access, CCTV, standard HVAC)
We have physical access controls but haven't been assessed against TIA-942 or EN 50600 standards
Minimal or no formal DC controls
On-premises server room with basic locks, no environmental monitoring or redundancy
Not applicable (cloud-only)
We don't operate any physical infrastructure
Phase 7: DC Governance & Data Sovereignty
28 of 30
What is your data centre Power Usage Effectiveness (PUE) and do you track thermal compliance?
Why this matters: ASHRAE TC 9.9 defines allowable temperature and humidity ranges for IT equipment. PUE measures energy efficiency (1.0 = perfect, 2.0 = 50% wasted). NABERS rates energy efficiency on a 1-6 star scale. Average global PUE is 1.58; best-in-class is below 1.2.
PUE below 1.3 with ASHRAE A1 compliance
Highly efficient. Track PUE continuously. ASHRAE thermal monitoring in place. NABERS 5+ star or equivalent
PUE 1.3-1.6, some thermal monitoring
Reasonable efficiency. Some environmental monitoring but not fully ASHRAE-compliant. May not track PUE continuously
PUE above 1.6 or unknown
Inefficient or not measured. No ASHRAE compliance. No energy efficiency rating
Colo provider manages PUE/cooling
We rely on our provider's efficiency. We may have SLA targets but don't directly control cooling
Not applicable (cloud-only)
Phase 7: DC Governance & Data Sovereignty
29 of 30
Do you have data sovereignty or data residency requirements for the jurisdictions you operate in?
Why this matters: India's DPDP Act 2023 restricts cross-border data transfer to notified countries only. Australia's PSPF requires government data on Australian soil. GDPR restricts transfers outside the EEA without adequacy decisions. Many organisations unknowingly breach residency requirements through cloud provider replication.
Strict sovereignty requirements (government/regulated data)
Data must stay in-country. No offshore replication. Applies to AU Government (PSPF), Indian data (DPDP), or EU personal data (GDPR)
Data residency preferred but not mandated
We prefer in-country data storage but some data may be processed offshore with contractual safeguards (SCCs, DPAs)
We process personal data of Indian citizens
Subject to India DPDP Act 2023. Requires lawful purpose, consent, Data Fiduciary obligations, cross-border transfer restrictions to notified countries only
Multi-jurisdiction (data crosses borders regularly)
We operate across multiple countries and need to comply with several data residency regimes simultaneously
No specific sovereignty requirements
We don't handle government data or data subject to residency restrictions
Phase 7: DC Governance & Data Sovereignty
30 of 30
What disaster recovery and business continuity capabilities does your DC infrastructure support?
Why this matters: Uptime Tier III requires concurrent maintenance without downtime. Tier IV is fault-tolerant. EN 50600 Availability Class 3-4 requires automatic failover. Your DR/BCP capability directly affects your audit outcomes under APRA CPS 232, SOCI, and ISO 22301.
Active-active / fault-tolerant (Tier IV / Availability Class 4)
Zero-downtime architecture. Multi-site active-active. Automatic failover. RPO near-zero, RTO minutes. Tested quarterly
Warm DR site (Tier III / Availability Class 3)
Dedicated DR site with replicated data. Concurrent maintenance capable. RPO hours, RTO 4-8 hours. Tested annually
Backup-only DR (restore from backup)
We have backups but no dedicated DR site. RPO 24 hours, RTO 24-48 hours. Manual recovery process
Cloud-native DR (AWS/Azure/GCP multi-region)
DR provided by cloud infrastructure. Multi-AZ or multi-region. Provider-managed failover
No formal DR capability
No documented DR plan or backup site. Single point of failure
1
A
Ace
Activitee Security Assistant
Hey there! 👋 I'm Ace, your Activitee security assistant. I can help with IAM, compliance frameworks, data privacy, and platform questions. What can I help you with?
Just now
Share info Powered by Activitee