Sending financial data off premises 2577
unclerico last edited by
We currently use a highly customized third-party ERP application that requires continuous modification/troubleshooting from the support reps. They want us to upload the entire contents of our database to them so that they can break down what is causing the issue(s). I keep telling them to log in via VPN and troubleshoot the issues in our development/test envrionment. They don’t want to do this. My main concern besides the size of the upload (> 15GB) is that our financial data is being transmitted via FTP (the contents are actually in an encrypted .zip file) into an uncontrolled environment. I have no idea who has the data and what they are doing with it. We are not in a regulated industry as of now, but we want to get there at some point so we in IT are attempting to align ourselves with the requirements of SOX. Would what I have described above be considered a deficiency/finding?
gmerkl last edited by
Do you have a separate development and a separate quality assurance (i.e. test development)? While the former will have very little data, the latter typically contains a copy of the production data that is refreshed frequently. This ensures that the testing happens in an environment that is realistically close to production and that also allows load testing. If you have a QA environment that is a copy of the production environment then the external guys have no excuse why it should not work in QA and their main inconvenience may be that the VPN connection is a bit slow.
unclerico last edited by
gmerkl, thanks for your reply. Yes, our QA environment gets a nighly copy of the previous day’s data from production. These support guys are adamant that they should still get uploads of the data as opposed to just working from our systems. I realize that this is our environment so we can tell them to take a flying leap, but I don’t just want to be an aUSDUSD here. I want to go to them and say ‘hey, this is a no no and here’s why’ and ideally the ‘here’s why’ part has some verbiage about SOX regulation since that’s what we want to abide by.
Denis last edited by
There is no SOX requirement you can quote back at them - although worse things have been done in the name of SOX. A better approach would be for you to define your data ownership, privacy and management standards and tell your vendor that they need to comply with them.
If they push back and say that it will make things harder for them to support then you can say that this is a risk that you can live with.
harrywaldron last edited by
My main concern besides the size of the upload (> 15GB) is that our financial data is being transmitted via FTP (the contents are actually in an encrypted .zip file) into an uncontrolled environment. I have no idea who has the data and what they are doing with it .
Hi - While I’m certain the vendor means well and desires to provide the best levels of support, I would recommend changes to strengthen security in the process. The key being the protection of the confidentially of any customer or financial data involved (which is a main theme of SOX 404).
Techniques can certainly vary in support programs, and the full upload may be needed at times to verify perhaps the entire integrity of a relational data base (e.g., indexes, views, referential integrity, etc). But it should be the exception rather than the rule, (e.g., only if the standard VPN approach doesn’t solve the problem and where the vendor has more industrial strength diagnostic tools at their site).
In your contractual arrangements, I’d ensure that the vendor uses a fiduciary approach as caretakers of any data being transmitted. They must not expose account information or privacy in any manner. Most vendors I’ve worked with adhere to these principles, but they should be constantly emphasized just to ensure there is appropriate awareness.
The changes make take and considerable discussion with the vendor. Keep expressing your concerns, as they are definitely security related and if financial information is involved there might be SOX 404 concerns as well.