Since FINRA has given firms the green light to use the cloud, it’s important to understand how to make it 17a-4 compliant. Because compliance officers don’t want to get caught with their pants down.
Especially when a regulator comes in for the electronic records request and can’t download a sample data set from the cloud. (Which by the way is what FINRA does during the 17a-4 electronic records request: ask for a sample set of data from the firm’s archive going back up to seven years.)
The Big Question About Microsoft 365 and 17a-4
The big question then becomes: can a cloud platform like Microsoft 365, using its built-in compliance tools meet 17a-4? Is it enough without adding a FINRA designated third party (D3P)? In other words, can you configure Microsoft 365 to prevent the deleting and modifying of emails on exchange, data on OneDrive/SharePoint, Teams chats, then retain it for 7 yrs., and finally will Microsoft act as the FINRA D3P, supply the two attestation letters and perform the required functions as a D3P?
I tried to figure this out myself, and – with my technical background it should be easy, but quickly felt I was sent on a fool’s errand. I then began thinking, how in the world can a small FINRA firm, without an IT department make Office 365 compliant? And this is important, failing to retain data for compliance can cause big problems.
Microsoft 365 Retention Policies Don’t Meet 17a-4
Now, according to a popular white paper by Cohasset Associates, FINRA firms can use Microsoft 365 retention policies (when properly configured and carefully applied and managed) to meet SEC rule 17a-4. Let’s go with this then and say a small firm decides to move their office to the Microsoft 365 Cloud. Meaning, they’ll host their email with the Microsoft Exchange system, store books and records on OneDrive for users’ personal storage, SharePoint for company shared storage, and Teams for video conferencing.
The first step then for making any system 17a-4 is ensuring no one can delete their emails. We won’t even talk about retaining electronic records because if a cloud platform can’t properly archive emails as per FINRA, its dead in the water. To prevent the deleting of emails stored on Microsoft 365 you need to apply an exchange on-line retention policy to users’ mailboxes, sounds simple enough, and surely Microsoft has a fancy web portal just for this.
So, I went ahead and tried to configure an exchange retention policy to retain emails in Microsoft 365 to meet 17a-4, and a red flag came up immediately. I noticed that a retention policy doesn’t really retain emails in a non-rewritable format: it just moves them to the archive items in Outlook, which the user can simply delete. I suppose if they do delete the archive item in their Outlook, these emails are available to search with the proper access to the eDiscovery tool, but I couldn’t actually recover any deleted emails through this tool. This is scary, because at this point the users don’t have their emails anymore, for example if you apply a retention policy, they are moved, and if deleted from Outlook they’re gone, this isn’t going to fly with FINRA. Not to mention the wrath compliance officers will face when users have all their old emails dumped to a completely different folder in Outlook.
PowerShell Commands Needed for FINRA Compliance
Ok, let’s continue with the theory that firms can use the exchange on-line retention policy so that emails are retained as per rule 17a-4, and that you are confident that if anyone deletes their email, you can access them using the eDiscovery tool built into Microsoft 365, and FINRA is happy with that. (Oh, and users have no problem with their emails being automatically moved around and deleted in Outlook without them knowing.) But wait! don’t forget that you need to do something else otherwise the admin can simply delete all the retention policies and email is no longer retained, oops.
You also need to configure and run PowerShell commands on the retention policies to apply preservation locks. Otherwise, any admin can simply delete them , and you’re back to square one. Now, I ask myself, do the experts who are promoting the Microsoft on-line retention policies for FINRA compliance think firms are going to run PowerShell commands to set locks on all their email retention policies? Trust me, it’ll never happen and even if they figure it out, its hard to maintain and would leave the door open to many errors and misconfigurations.
Microsoft won’t Provide the 17a-4 Attestation Letters
Ok, but let’s say you do apply all the proper retention policies to users exchange mailboxes then successfully run the required PowerShell commands to apply preservation locks to them, you then need to get the two FINRA D3P attestation letters from Microsoft. This must be done to meet 17a-4 and a FINRA firm needs these letters from the provider that is archiving their data proving it’s retained properly. One letter is the 17a-4 Broker Dealer Letter and the other is the 17a-4 3rd Party Storage Provider Letter. We won’t even get into details of what the D3P’s responsibilities are; if they won’t provide the letters, its dead here as well.
At this point I didn’t even try to call anyone at Microsoft to ask if they could provide the FINRA D3P letters, in fact I have no idea what number I should call, so I went ahead and googled “Microsoft FINRA 17a-4 D3P letters.” I was then directed to a site with a link to download a document explaining the capability of Microsoft 365 to support organisations in meeting their obligations under the New Zealand Public Records Act 2005. Huh? A New Zealand Records Act from 2005? Something was fishy about this.
I then did more google searches and found another expert claiming that firms can download a copy of the 17a-4 letters from The Microsoft Trust Center Resources. (I guess a copy of the letter is a good start, however, the D3P letters must be customized for each customer- but I won’t get into that either.) Of course, this led me to another link to a Microsoft site, but the 17a-4 attestation letters were nowhere to be found, it didn’t get me anywhere, and it surely didn’t have other links to a FINRA 17a-4 attestation letter from Microsoft, at that point I gave up.
Summary:
I understand that Microsoft wants to have a finger in every pie; to be everything to everybody, but certain customers have unique data compliance demands, such as small FINRA firms, which cannot be met with a generic cloud solution. More importantly, firms don’t have the in-house expertise to “configure and carefully apply and manage” the built-in tools that Microsoft is selling as 17a-4 compliant. Finally, firms need specific compliance documentation and commitments from vendors to be fully compliant, which Microsoft is obviously not willing to provide or even openly address.
To learn more about the AdvisorVault solution to make Microsoft 365 17a-4 compliant, click the link below to speak with sales:
