Technology
**End of secondaryNav**>
Technical FAQs
What are the technical specs for your software?
StarCompliance software is run on the Microsoft Windows Server. It's written in C# using the .net 3.5 framework within the Visual Studio Team Server and using an agile methodology.
Was your application developed in-house or by a third party?
Our software was (and is) developed in-house and does not use any third-party components. For security purposes, however, a third-party security company frequently audits our code base and application.
Not finding the answers you're looking for call us on 1 301.340.3900 or Contact our team
StarCompliance prepared the following 5 questions for financial institutions to ask compliance software providers about their data control measures:
Question 1: Where will our data be hosted? Behind our firewall or externally?
The best practice for ensuring data is safe and secure is for a financial institution to host the system in-house or to choose a hosted solution with a single tenant architecture where employee information is stored in a dedicated database. This gives you more control over the system and who has access to it and also eliminates any possibility of one financial institution getting access to another institution’s data.
If data is stored externally, what are the key security risks we need to address?
Many software providers only provide externally hosted solutions because they use system architectures that leverage common system resources for use by multiple clients. This is what is commonly referred to as a multi-tenant SAAS model. Multiple users from multiple firms share a common database for storing information. The software is hosted on remote servers that are accessible over the Internet through a web browser. While this may be cost-effective from the software provider’s perspective, it typically does not give a financial institution the ability to host the application behind its firewall. When the software is hosted by the multi-tenant provider, there is a risk of one firm gaining access to another firm’s information because, although partitioned, all data is stored in a common database
Question 2: Will our data be held on a system alongside the data of other organizations? What risks does that potentially pose to our data? What controls do you have in place to ensure no cross over of data occurs?
The decision on whether or not the software provider should host the software for your financial institution should take into account how the database system is architected. Choosing a provider with a multi-tenant SAAS model can pose serious security risks due to the commingling of different customers in the same database. Instead, it is recommended that you choose a software provider that does not store customer data in a shared database and that all of its customers have their own instance of the software running on their servers, also referred to as single-tenant. This design benefits the security of your data by relying on the software provider for software hosting services while at the same time reducing the risks associated with multiple financial institutions sharing the same instance of the software and therefore avoiding commingling of your data with another institution within a single database.
Question 3: What outside parties have access to our data?
A common business practice of software providers is to use sub-contractors to build and maintain major components of their software and these outside parties often have access to customer data. When outsourcing this development, it is possible that a software provider may focus too heavily on associated cost savings which can jeopardize the quality and integrity of people assigned to a given project. Furthermore, this approach may introduce the risk that the sub-contractor’s employees may not undergo the same level of background checks as would have been followed had the software provider hired the employees directly.
Question 4: What type of security clearance process do your employees and subcontractors go through? What types of authorization controls are in place for access to our data by employees and subcontractors?
It is common business practice for software providers to rely on a combination of permanent and contract employees to develop and release new features and functionality. While this offers the benefit of faster times to market, it does introduce additional risk that relates to the level of access the software provider’s permanent and contract employees have to the financial institution’s data. When a financial institution installs the software in-house, the access to data is completely protected from the software provider’s staff members. However, there will be a need for the software provider to assist financial institutions with managing their software and the data it contains. This makes it necessary for the software provider to conduct background checks on its permanent and contract employees. This will ensure the people relied upon are trustworthy. The background checks should be a combination of criminal, credit, employment and education verifications.
There are going to be times when the software provider will need to help you with incidents that require access to employee and firm data. It is important for procedures and system controls to be in place so that no access to your institution’s data is permitted without granting permission to the software provider. These procedures should be evident when an onsite security audit is conducted as well. The software provider’s policies and procedures should indicate the steps that need to be taken for an employee to be given access to your production systems and data.
Question 5: Our organization is multinational; does your software meet data protection and compliance regulations in all the territories in which we operate?
Data protection and compliance regulations differ between states and countries. Some may prohibit company and employee data from leaving the country, or being hosted externally. Therefore, multinational financial institutions should consider installing the software internally. Alternatively, you should conduct a security audit of the software provider and its hosting facility to verify adherence to privacy laws, such as the US-EU Safe Harbor Framework and Swiss Privacy Laws.
