Is Your Firm's Reporting Platform Actually Secure? What to Check
Every accounting firm considering a new reporting platform eventually asks the same questions: where does our client data go, who can see it, and what could happen if something goes wrong?
Those are not questions to leave until the end of a software evaluation. Accounting firms hold sensitive financial, commercial and personal information. A reporting platform may only sit “on top” of the practice management system, but it can still process, store or display a substantial amount of that data.
The right security review therefore goes beyond asking whether a product uses a reputable cloud provider. It should examine the complete data path, the permissions granted at each stage and the controls that determine who can access the finished reports.
Start with the complete data flow
Before evaluating certifications or security features, ask the provider to show you how information moves through the solution.
You should be able to identify:
which source systems the platform connects to;
what permissions each connection receives;
what data is extracted and what is excluded;
where extracted data is processed and stored;
whether temporary files, backups or logs contain client information;
how data reaches the reporting layer; and
how users view, share, download or export it.
A simple architecture diagram is often more useful than a page of general security language. If the provider cannot explain the journey clearly, the firm cannot properly assess the risk.
Microsoft infrastructure is a strong foundation but not the whole assessment
A reporting platform built on Microsoft Fabric and Power BI starts with a mature, integrated data and analytics environment. Microsoft publishes detailed information about Microsoft Fabric security and Power BI security, including identity, encryption, network communication and data storage controls.
That is a meaningful advantage, particularly for firms already using Microsoft 365 and Microsoft Entra ID. It can reduce the number of unfamiliar platforms and identity systems the firm needs to manage.
However, using Microsoft infrastructure does not automatically make every solution built on it secure or independently certified. Cloud security follows a shared-responsibility model: Microsoft secures the underlying cloud services, while the solution provider and customer remain responsible for matters such as configuration, identities, access, data handling and user devices.
The practical question is not simly “Is it built on Microsoft Fabric?” It is “How has the provider configured, operated and monitored the complete solution within Fabric?”
Check identity and access controls
A secure platform should make it difficult for the wrong person to gain access and straightforward to remove access when somebody changes roles or leaves the firm.
Ask whether authentication is managed through the firm's Microsoft Entra ID tenant and whether the solution supports the firm's existing controls, including:
multi-factor authentication;
Conditional Access policies;
least-privilege access;
defined administrator roles;
controlled service accounts;
prompt staff offboarding; and
regular access reviews.
This is more important than having a polished login screen. The real test is whether access is linked to an identity the firm governs, protected by appropriate policies and removed consistently when it is no longer required.
Understand row-level security and report sharing
Different users need different views. A partner may need firm-wide visibility, a manager may need access to a team or portfolio, and a staff member may only need their own performance information.
Row-level security in Power BI can enforce those distinctions within the data model. Properly implemented, it is much stronger than hiding a page, filter or navigation button in the report interface.
But row-level security is not automatic. It must be designed, tested and maintained. The review should cover:
how users are assigned to roles;
whether access reflects the firm's current organisational structure;
who can edit or administer workspaces;
whether report sharing, export and “build” permissions could expose additional data;
how changes are tested before release; and
how often permissions are reviewed.
Ask the provider to demonstrate the same report as a partner, manager and staff user. The firm should also test edge cases, such as a manager changing teams or a person belonging to more than one role.
Verify data residency precisely
“Hosted in Australia” can mean different things. Power BI stores tenant data according to its home geography, while some multi-geo configurations can place content in other geographies. Microsoft also notes that certain metadata and processing can remain associated with the home geography.
An Australian firm should therefore ask for a more precise answer than a single hosting location. Confirm where each of the following occurs:
extraction and staging;
primary data storage;
Power BI content storage;
backups and disaster-recovery copies;
logs and monitoring data;
support access; and
any subprocessors or connected services.
Data residency can support a firm's risk and compliance requirements, but it is not a substitute for access control, encryption or sound operational security.
Confirm encryption across every layer
Microsoft states that Power BI encrypts data at rest by default and uses secure transport protocols for data in transit. That is important, but the reporting service is only one part of the data path.
Ask how information is protected while it moves from the practice management system into Microsoft Fabric, while it is staged or transformed, when it is backed up and when it is exported by an authorised user. Also confirm who manages encryption keys, whether customer-managed keys are available or necessary, and how secrets used by connectors or service accounts are stored and rotated.
The goal is to avoid a well-secured dashboard sitting at the end of a poorly secured extraction or staging process.
Why read-only access matters and what it does not solve
Read-only access to a source system is a valuable risk control. It reduces the chance that the reporting layer could accidentally change or delete practice-management records, post transactions or interfere with operational workflows.
It does not remove every risk. A compromised read-only connection may still expose confidential data, and a reporting platform may hold copies or transformed versions of source information. Incorrect permissions, unsafe exports or an exposed service credential can still cause a serious incident.
Ask the provider to confirm that source access is technically restricted to the minimum data and operations required—not merely described as read-only in the user interface. The firm should also understand how credentials are protected, how access is logged and how quickly it can be revoked.
Ask for operational security evidence
Certifications and attestations can be useful evidence, but their scope matters. A Microsoft certification covers the Microsoft services named in that certification; it does not necessarily cover the reporting provider's own processes, configurations or support practices.
Ask the provider for current, specific evidence covering the service you will use. Depending on the firm's requirements, that may include:
applicable certifications or independent assurance reports;
vulnerability management and penetration-testing practices;
security logging, monitoring and alerting;
incident-response and breach-notification procedures;
backup, recovery and continuity testing;
employee and contractor access controls;
subprocessor information;
data retention and secure deletion; and
a clear process for reporting security concerns.
The answer does not need to be a folder full of certificates. It does need to be specific enough for the firm to distinguish independently verified controls from marketing statements.
A practical security checklist for accounting firms
Before approving a reporting platform, confirm that the firm can answer these questions:
What information leaves each source system?
What exact permissions does the provider receive?
Where is data processed, stored, backed up and logged?
Who can access the data within the provider's organisation?
How are users authenticated, authorised and removed?
How are partner, manager and staff views technically separated?
Can users export or reshare information, and how is that controlled?
What encryption protects each stage of the data path?
What security claims have been independently assessed, and what is their scope?
How are incidents detected, communicated and contained?
What happens to the firm's data when the contract ends?
Which security responsibilities remain with the firm?
Strong answers should be documented in the contract, implementation design or security material, not left as verbal assurances from a sales conversation.
How Practice Clarity approaches the reporting layer
Practice Clarity is designed as a reporting layer over the practice management systems firms already use. Practice Clarity uses read-only access to source systems, processes and secures data within Microsoft Fabric, and delivers reporting through Power BI with row-level security.
This architecture can provide a strong starting point: the operational source remains in place, reporting is delivered through Microsoft's established cloud and identity ecosystem, and access can be tailored to the user's role.
As with any security-sensitive implementation, the final protection depends on the agreed data scope, configuration and operating controls. Those details should be confirmed during evaluation and implementation so the firm understands both the platform's controls and its own responsibilities.
Security should not be treated as a vague promise that a platform is “enterprise grade.” It should be a set of controls the firm can see, test and understand.
Frequently asked questions
What should an accounting firm check before adopting a reporting platform?
Check the complete data flow, source-system permissions, identity and access controls, row-level security, data residency, encryption, exports, incident response, retention and the scope of any independent security assurance.
Does using Microsoft Fabric and Power BI automatically make a reporting platform secure?
No. Microsoft Fabric and Power BI provide mature security capabilities, but the provider and customer remain responsible for configuration, identities, permissions, data handling and operational controls.
Why does read-only access matter?
Read-only access reduces the risk that a reporting tool could change or delete source records. It does not eliminate confidentiality risks, so permissions, credentials, storage and report access still need to be secured.
Is row-level security enough to protect confidential reporting data?
Row-level security is an important control, but it must be correctly designed and tested alongside workspace roles, sharing, export permissions and identity controls.
Can an Australian firm keep its reporting data in Australia?
Microsoft provides regional data-location options, but the firm should verify the location of each component, including staging data, Power BI content, backups, metadata, logs and support processes, rather than relying on a general hosting statement.
If you want to understand how Practice Clarity would connect to your systems, secure access by role and deliver reporting through Power BI, book a walkthrough.