Security & privacy built in, not bolted on
6-layer security model. Data hosted in Microsoft AU datacentres. Granular access control. Complete audit trails. Your data is your data—no resale, no third-party access.
6-layer security model
CRM for NFP inherits Microsoft Dynamics 365's enterprise security architecture. Every layer is configured for Australian NFP requirements.
Access control in plain English
Security groups
Purpose: Define broad access based on job role
Example: "Case Managers" group can create cases and view client records. "Finance" group can view funding records but not client case notes.
Why it matters: Staff only see what they need to do their job. No manual per-user configuration.
Record-level permissions
Purpose: Control access to specific records within a table
Example: Case workers see only clients in their region. Managers see their team's cases. Leadership sees aggregated reports without individual case detail.
Why it matters: Multi-site organisations can operate in one system with data segmentation.
Field-level security
Purpose: Hide sensitive fields within records
Example: Everyone can see a client's name and program enrolment. Only "Clinical Team" can see mental health diagnosis field. Only "Leadership" can see salary information for staff records.
Why it matters: Privacy by design. Compliance with need-to-know principles.
Audit trails
Purpose: Track all access and changes
Example: See who viewed a client record, when, and what fields they accessed. See complete change history: who changed what field from what value to what value, and when.
Why it matters: Accountability. Incident investigation. Compliance evidence.
Sensitive information examples
Not all NFP data needs the same protection level. Here's how to think about sensitivity:
High sensitivity – field-level security required
- Health information: Mental health diagnoses, disability details, medical history
- Vulnerability flags: Family violence indicators, child protection involvement, financial hardship details
- Financial details: Bank account numbers, income details, debt information
- Legal status: Visa status, criminal justice involvement, legal proceedings
Medium sensitivity – record-level permissions sufficient
- Case notes: Service delivery history, support plans, referrals
- Contact details: Phone, email, address (but consider vulnerability flags)
- Program participation: Which programs someone is enrolled in, attendance records
Low sensitivity – security group access adequate
- Membership information: Membership type, expiry date, renewal history
- Event registrations: Who registered for which public event
- General communications: Newsletter subscription, communication preferences
Australian data hosting
Your CRM for NFP environment is hosted in Microsoft's Australian datacentres (Sydney or Melbourne). Data does not leave Australia unless you explicitly configure integrations that require it.
Data sovereignty
Data remains within Australia's jurisdiction, supporting compliance with Australian Privacy Principles and local regulatory requirements.
Funder requirements
Many government and philanthropic funders require Australian data hosting. CRM for NFP meets this requirement by default.
Latency & performance
Local hosting means faster response times for Australian users and better performance during business hours.
Privacy stance
Your data is your data. No resale. No third-party access for advertising or analytics.
What this means:
- Your client and stakeholder data belongs to you, not to Mayasoft or Microsoft
- Data is not used for any purpose outside your organisation's operations
- Data is not shared with third parties except as you explicitly configure (e.g., Stripe for payments, email marketing platform)
- You control data retention, export, and deletion in line with your privacy policies
- Microsoft does not train AI models on your CRM data
Security questionnaire readiness
Funders, partners, and regulators often require security questionnaires. CRM for NFP is designed to answer these questions:
- Where is data hosted?
Microsoft Australian datacentres (Sydney or Melbourne) - What certifications does the platform have?
ISO 27001, SOC 2 Type II, IRAP (via Microsoft Dynamics 365) - How is access controlled?
Security groups, record-level permissions, field-level security, MFA required - Are there audit trails?
Complete access and change logging for all records and fields - How is data encrypted?
Encryption at rest (AES-256) and in transit (TLS 1.2+) - How is backup handled?
Automated daily backups with point-in-time recovery - Can data be exported?
Yes—full data export capability for portability - Who has access to data?
Only your authorised staff. Mayasoft support requires your explicit permission per incident. - How is vulnerability management handled?
Microsoft manages platform security patching. Mayasoft monitors security advisories. - Is penetration testing performed?
Microsoft performs regular penetration testing on Dynamics 365 platform
Frequently asked questions
Can I control which staff see which clients?
Yes. Use record-level permissions to control access based on ownership, team membership, or region. For example, Melbourne case workers see Melbourne clients. Managers see their team's cases. Leadership sees aggregate reports without individual case access.
How does field-level security work in practice?
Field-level security hides specific fields from users who don't have permission. Example: everyone sees a client's name and contact details. Only the "Clinical Team" security group sees the mental health diagnosis field. If a user without permission tries to access the field via API or export, it's blocked.
What happens if someone leaves the organisation?
When a staff member leaves, their user account is deactivated. They lose all access immediately. Their records (cases they created, notes they wrote) remain in the system with full audit trail. Records can be reassigned to other staff members.
Can I see who accessed a client record?
Yes. Audit logs show who viewed a record, when, and what fields they accessed. This supports incident investigation and privacy compliance. Audit logs cannot be deleted by users.
Is multi-factor authentication (MFA) required?
Yes. All users must use MFA via Microsoft Entra ID (formerly Azure AD). This is enforced at the identity layer before users reach the CRM.
What if we have multiple sites with different data access requirements?
Use teams and record-level permissions to segment data by site, region, or program. Each site's staff see only their records. Shared records (e.g., multi-site clients) can be configured with cross-team visibility.
How is consent for communications tracked?
Consent is captured as fields on contact records: email consent, SMS consent, marketing consent. Consent history is logged (when given, when withdrawn). Communications module respects consent flags automatically.
Can we restrict access to specific modules?
Yes. Security roles define which modules and features users can access. Example: "Membership Coordinator" role has access to Memberships module but not Client Case Management.
What documentation is available for security audits?
Mayasoft provides security overview documentation. Microsoft provides Dynamics 365 compliance documentation (certifications, security controls, data processing agreements). Your organisation's security configuration documentation can be generated from the system.
How does CRM for NFP handle data breaches?
Microsoft manages platform-level security incidents. If a breach affects Dynamics 365, Microsoft notifies affected customers per their incident response process. For organisation-level incidents (e.g., compromised user account), audit logs support investigation and evidence for notification obligations.
Security questions?
Book a conversation to discuss security requirements, access control scenarios, or compliance questionnaires.
No hard sell. Just a practical discussion.