Information Security is a broad reaching area of concern for your business. In the enterprise world a large component of this is part of their GRC efforts which can be over-whelming for a smaller organisation.

Governance, Risk, and Compliance

One commonality between enterprise and startups is the reliance on vendors.
At the enterprise level you may choose a vendor to take responsibility for certain business functions for various reasons but for startups it is a necessity that you don't reinvent the wheel.
As a startup you must focus efforts on your value prospect, what differentiates you in whatever market you're competing in.

For the purposes of this post I'll use a fictional FinTech startup.

I'll also use the lens of Information Security with consideration for Solution Architecture on AWS because

Cloud!

Ok, so this is essentially DevSecOps for those up-to-date with buzzwords.

Vendor selection

Commonly called Software Selection interchangeably.

While a business process for Vendor selection may include request for information, quotation, proposal, pricing etc, as well as proposal evaluation. These and a boring list of other business oriented activities.

It's up to you if you complete these though I strongly suggest the startup at-least complete the business requirements statement, preferably a formal business case report that conveys a clear message from stakeholders and directors.

For us concerned with Information Security, specifically due diligence, the following activities are required;

1. Discover the Vendors legal name and business registration status.
   • In Australia search ASIC's registers and notices.
2. Do a thorough web and social media search (OSINT) on the company, products, and services
3. Perform an analysis on the directors and stakeholders for conflicts of interest, and discover the employees whom you will be working with. Some organisations will supply you the CV of personnel upon request
4. Review the vendors public MSA, Privacy Policy, and any legally binding agreements on conduct that may provide additional powers to the vendor with restrictions to your business and its operations

Some of these tasks are time consuming so the logical order plays a role here. By the time you get to the point where you are reviewing the legal documents any red flags should have sent you back to your superiors to see if you should short-circuit this due diligence exercise.

Additionally, the review of the legal documents should remain high level. You are conducting due diligence and should avoid the more thorough legal scrutiny yourself.
Be sure you seek legal advice before any commitments are made to a vendor regardless of what you identify, however you should review them yourself as part of due diligence as not all red flags are legal oriented, you may find incompatibilities with your business requirements and operations that legal council will not identify, such as a domain registrar having the right to take down your site if they detect user content that violates their policy whether or not you moderate.

Qualitative analysis

For those not familiar with the terminology, put simply this is a process where you look at the qualities of something without applying calculations, which is good for analysing features that are inherently unmeasurable.

Activities that will help you document a report are;

• Analysis of software functionality or vendor services rendered.
• Maintenance and support
• SLA (Service Level Agreement)
• Interoperability (not just for exit strategy)

While the findings may appear obvious to you, and in most cases you've done this many times and never needed to create documentation for it. The real benefit recording these activities is you've demonstrated that you applied a high level of analysis to the selection process and transparently followed a business process which applies the business interest. Your employees will also benefit from your efforts as a lot of these tasks are done, documented, and often would need to be done in future after the fact of not documented the first time doubling your efforts overall.

As a FinTech start up you are obligated to present a case to regulatory authority (APRA in Australia), or you may be obligated to pursue a PCI Audit. In both cases you will be required to demonstrate due diligence and risk assessment capability through many types of collateral as evidence.

Risk Assessments

A crucial process, but one that is often over looked by small businesses and startups. Once again this seems like a massive effort but it doesn't have to be.

This particular section could mean the difference between success and failure in more areas then you first expect. Besides the benefits for Information Security, demonstrating risk analysis is valuable to your investors and a skill you can use to evaluate future partnerships.

The key to a quicker risk assessment is to apply a widely accepted framework rather than develop your own processes. There are many frameworks and guides but the efficient choice I recommend for small to medium business is the CIS RAM (Risk Assessment Method).

If you wish to develop a more mature process beyond the CIS RAM the next easiest step is combining the CSA CCM (Cloud Security Alliance Cloud Controls Matrix) as a guide on inherent risk analysis, apply effort in Threat Modeling, and your own Risk Vulnerability Model. At this stage you might also be interested in the NIST guides.

Controls Implementation

Hopefully you've applied a the inherent risk assessment to save you time coming up with a concise set of controls appropriate to your circumstance. It's overkill and wasted effort to apply every control that exists if they're not prioritised based on the threat model.
It is hard for anyone to come up with controls regardless of their experience, so I recommend you check with the controls offered by CIS to get started. If you feel the controls aren't meeting your expectations (and you have time) it is also useful to review the various standards and compliance reports to get the brain working and help you come up with more appropriate controls, a good reference is the PCI DSS RoC.

Controls Evaluation

Controls are the whole reason for your Information Security strategy to exist. It is not worth the effort in implementing them if you have no idea of their effectiveness.

A typical evaluation is quite manual however there are tools that automate the task such as Cloud Conformity and Qualys from the outside looking in, or my personal favorite Lynis when looking at a host.

Your controls evaluation report should be conducted periodically, some compliance obligations are prescriptive in this case but if you have none of these obligations you might find it useful to do annually or as a task for a new hire in a senior level position as it is a good way for them to become familiar with your systems and encourage a culture of security.

The goals for documenting the Controls Evaluation are to address each control identified and implemented with a testing procedure and that tests result, a fairly simple process but one that provides a great deal of assurance to the controls effectiveness and your companies security posture.

Keep the Controls Evaluation as high level as possible, don't allow any scope-creep to bloat the report for 2 reasons;

1. This is the ideal document to provide confidentially to business partners or investors.
2. With greater complexity auditors will apply a higher degree of scrutiny.

Keeping it simple also makes the task itself more approachable for non-security trained staff, new employees, or for the team member to annually conduct as it should be much less complicated then the risk assessment or due diligence processes.

Conclusion

The formal process is not as important as the businesses ability to provide implementation detail evidence of their security posture and risk appetite.

You aren't going to be faulted for demonstrating through evidence that is showing the results of your efforts. However if you have processes but cannot produce any collateral of them being followed will do more harm to your security posture then if you had no formal processes at all.

As a lean startup, skipping formal processes is unlikely to hold you back from achieving the licensing or compliance you need. If you can show a higher than expected degree of risk mitigation through evidence, then you're practically more secure then most.