The second part of this mini guide. the first part is here: http://jacquesmattheij.com/Due+Diligence+survival+guide .
What I’ve done is to analyze the lists of questions and main subjects from past due diligences to give you an idea of the areas that are generally touched on.
Note that this is not a ‘full’ list by any stretch of the imagination, every company is different and I spend a fair amount of time customizing the process to the target company.
So the list here is pretty much limited to those things that hit just about every company, no doubt there are exceptions to that (and no doubt there are things missing), but the majority of these should apply to your company too if you are active in technology, especially if your company has a software component or product (and that’s the vast majority of technology companies these days).
Another remark that I think is really appropriate here is that all these things are important regardless of whether or not due diligence is being or is going to be performed on your company. Typically start-ups get a lot of leeway in cutting corners but you should at least strive to be ‘ready’ for an in depth review of your company, that means that you’re in good shape. If you have to make major moves in order to be able to pass a due diligence you have serious problems that you should probably attend to immediately or at least in the very near future. In other words, if anything on this list is ‘news to you’ you should get moving sooner rather than later.
For some things there are excuses, for other things there really are none. For instance, if you are very tight on funds you may not be able to afford certain items that would make your business more likely to survive in the longer term but you have decided to take that risk consciously. But being ‘short on funds’ is no reason to for instance not have backups of your source code repositories or production data.
You can use this mini guide as a way to prepare for a due diligence but again, this list is not exhaustive and you’ll need to adapt it to suit your company. You could also crib this list and use it to start doing due diligence on other companies but there are a couple of warnings that apply to doing that:
- if you could not come up with this list by yourself you probably shouldn't be doing that
- there is much more to dd than just compiling a list of questions and getting the answers to those questions
- some of these questions will lead to a large number of follow up questions
- it's the interpretation of the answers and the 'on the fly' generation of follow up questions that matters, not the questions themselves
- in some circumstances even these 'general' questions make no sense, for instance, you'd approach a start-up in a completely different way than a company that's been operating for years
- One of the reason you won't find any lists like these on the internet is because the people doing dd typically consider these their 'best guarded secret'. Just like 'open source' I don't think the code (the list) is of much value, it is the service around the code and the decades of experience working with technology that make a person good at this.
What you’re also going to miss is the ‘bs’ questions, I don’t work for one of the big auditing companies that do this work and I permit myself some artistic license when it comes to evaluation. Of course it is possible to create a ‘script driven’ auditing process where each and every little detail is going to be investigated ad nauseum, but it is my nsho that this is a total waste of everybody’s time. After all, if that were the case you could do due diligence in a ‘self service’ format and I believe that that is definitely not the case. Of course such a ‘script driven’ due diligence process allows you to send people with limited technical experience into the field to gather data but they will come back with haystacks instead of with needles. Of course if your end products are powerpoints, pretty graphs and reams of paper instead of actionable information it helps to have as much hay as possible. I also don’t do weasel words in reports ;)
A proper due diligence will concentrate on the material facts and on the ability of the people working for the target company to deliver and maintain a quality product and to assess the risks insofar as these are not inherent in operating a business and to uncover any items they may have missed in the course of doing their jobs.
A large omission in these pages is the subject of security. There are two reasons for that: the first is that security is a subject that is hard enough that I think that you’d need to dedicate your life to it in order to get out of the ‘knows enough to be dangerous’ realm, secondly it is a field that moves so fast that anything that I’d write down here would be obsolete by the time the virtual ink had dried.
If a company has a significant web facing component then they should have people that are dedicated to security and that portion of the company (and any other network related components) should be audited by security professionals rather than by ‘generalists’. The components of a security strategy are reasonably well known, the actual implementation of such a strategy and the auditing thereof is an area for specialists. If a company has a significant web facing component and does not have people dedicated to security (either in their employ or hired from a reputable firm) there are almost certainly issues but I would not be qualified to uncover those unless they’re glaringly obvious.
On another note, if you think some - or even all - of the questions in the lists below are trivial, stupid and should never be asked you’re probably going to be surprised to hear that over the years each and every one of these has proven to be useful in at least one (and usually more than one…) instance.
With that out of the way, let’s continue to the list of subjects, I’ve left out the reasons for these questions, I assume that if you’re reading this that you’re more than smart enough to figure out the reasoning by yourself, if it is unclear why a certain question would be relevant feel free to mail me (jacques@mattheij.com) and I’ll do my best to explain. It’s important to remember that this is a sample and that the list would be heavily customized with both deletions, changes and additional questions for any particular target, this list is a starting point and not the be-all-end-all.
- People
- Are there single individuals that are critical to the survival of the company?
- If so, why and how long would it take to spread the required knowledge/skills?
- How long does it take to get people trained for various positions?
- How many employees are there in the technical departments?
- What is the organizational structure?
- Are the people experienced or new to the game?
- Are they using freelancers?
- If so in which positions?
- How much of the knowledge critical to development and operational aspects of the company is vested in outsiders?
- Do they have procedures in place for new hires and leaves?
- If so, description of those procedures?
- What is the turnover of the various parts in the technology departments?
- When was the last hire for each of these?
- How fast are the various departments growing?
- How long does it take to get new people up to speed?
- How big is the 'core' of people that run the technology department?
- Do they have open positions? How many?
- Have there been recent 'bad leaves'?
- Development
- What does the development environment used look like?
- Are they doing software development?
- Are they doing hardware development?
- Are they using a source code control system?
- How do they back-up the sources?
- How many people are active in the development department?
- What do their test procedures look like?
- Is the test environment representative of the typical end user of the product?
- Dedicated Q&A people?
- Are there components used in the development process that are no longer supported and/or available from their manufacturers?
- Are they on board with some software development methodology?
- If so is this a religion or a guideline?
- Do they practice code reviews?
- Let's look at that code
- Let's look at the documentation (systems level, code and end user)
- Who has access to the source code?
- What does the deployment process look like?
- If they're doing hardware development in house ohsa regs, review workplace
- If they're doing hardware development in house have a look at the product
- Hardware UL/CE approval procedure?
- IP
- Are they using third party source code to be integrated into the final product?
- If so what are the licenses under which this source code has been released?
- Are they integrating third party 'closed source' components?
- Are all those still actively supported?
- Are there any uses in violation of the licenses?
- Are domain names used to conduct business registered to the right entities? (ptr to legal)
- If outsiders do development is there proper contractual transfer of IP?
- Roughly how large is the portion of software that has been developed in-house?
- How much of the value of the company is vested in the IP?
- Legal
- Do you send email to your visitors?
- Are you aware of and compliant with spam legislation?
- Are you aware of and compliant with privacy legislation?
- Are you aware of and compliant with data retention legislation?
- Software
- Is there a license administration for all the software used by the company (both development and production)?
- Are they still using legacy software that is no longer maintained by the original manufacturer?
- Tickets?
- Hardware
- Is the hardware the company uses leased or owned? (ties in with fdd)
- Do they have maintenance contracts on the hardware?
- Are there critical hardware components of which they've got only one?
- Is there a hardware inventory? (copy please)
- Are they using legacy hardware (unsupported, no longer available) in critical spots?
- Production
- Diagram of the production environment?
- Any single points of failure? (lines, gear, services, provider)
- What does the software stack look like?
- How fast does the production environment grow?
- What is the fastest growing component? What does the growth curve look like?
- Figure out where the bottle necks of the current production system are and how future proof it is
- Is there a solid plan to meet the growth for the foreseeable future?
- How many people are responsible for operations?
- Do they do their own system administration?
- Do they do their own application level administration?
- Do they use a monitoring service?
- Failover automated or manual?
- Hosting facility?
- Use of 'cloud' services?
- SAAS components that are critical to the business?
- A list of SLA's and contracts for critical components?
- Copies of those?
- Customer support (first line) in house?
- Support Ticket system?
- If so does that integrate with support system further up the line?
- If they have a web facing component do they have people dedicated to keeping the place secure?
- And if they do, do they use other people to check up on the former?
- Do they handle physical goods?
- Do they handle physical goods owned by others?
- How easy is it to gain physical access to the various departments?
- What is the backup regime?
- Do they do trial restores of backups?
- Off-site backups?
- Who has access to the backups?
- Do they store end-user data?
- If so, what data is being stored?
- Are they aware of the relevant data protection acts and are they in compliance?
- Does the company give out SLA's to users of the product?
- If so, copy of those, cc legal
- Do they use an analytics tool?
- If so access
- Do they send out email to end users?
- Aware of various laws regarding email, double opt-in etc?
- Are all the main components of the stack IPV6 ready?
- Who has (physical/network) access to the production systems?
I hope that this was useful to you, if you have questions or feedback feel free to email me: jacques@mattheij.com .