Repost - Security Design - Be an enabler not a blocker
When liaising on projects, as a security architect it’s important to not spring surprises on your project manager. Most project managers tend to react with an involuntary facial twitch to "new requirements", these are often are associated with project delays and cost overruns.
So to avoid surprises and make your engagements with a project smoother, consider the following:
Draw out compliance requirements early in the business case phase
Develop detailed security requirements that are specific and technology agnostic. Also, detail the importance and difficulty/cost of the controls at a high level. (Eg. not so much: “the system must be secure”, but more like: “the system must support TLS for protecting transit of classified information”.
Give the project options even when they are limited. For example: "You need this control for compliance purposes but it’s difficult to implement in the project timeframe, can I help you apply for a temporary security policy exemption?”
Choose standardisation over specialisation. A standard security control inherited from an environment is more likely to be maintained than a custom one deployed only for a single project.