A big hurdle is that when you hire the first dedicated person into a new domain (be it UX, Embedded, Security, EE, Legal, Finance whatever.) you often don't rea

A big hurdle is that when you hire the first dedicated person into a new domain (be it UX, Embedded, Security, EE, Legal, Finance whatever.) you often don't really understand the domain well enough to know what you need. You should also be thinking that rather than this person doing all the work themselves they should be educating the rest of the company in this area. They need to be experts, they also need to be good "people" people. You probably already got lots of "not experts" in those areas ;) Security is very multi-faceted. Securing your internal/IT applications is very different than writing secure code which in turn may be different than some other specialized situation. Ideally you already have some people who have some clue and/or have seen something that works somewhere else from an organizational perspective (or have seen things that don't work that you don't want to repeat). E.g. you may have some IT person who isn't a security expert who has worked in a team that had a stronger security bias/expertise and has seen how that team worked/was structured. You may have a senior coder who has pretty solid ideas about security but it's not his main expertise. Leverage that stuff! Talk to those guys about how to build the team...