"Assumptions" are a subtle concept. I would suggest that you consider all the factors that might affect your project's success
if you can manage the factor (if it fits into one of the PMBOK processes), then manage the factor. Cost, schedule, quality, configuration, etc. Manage what you can.
if you can't manage the factor treat it as a risk - estimate the probability/frequency/impact, and mitigate those you can. The first step in risk management is to collect enough information to make an estimate.
if you can't estimate the factor - if there is simply too much unknown, then make an assumption. Once you've made an assumption, document the risk. Assumptions are (loosely speaking) risks that are too expensive to estimate with any degree of confidence. This can be because the information needed for a quality estimate are not yet available, or it can be because there is a fundamental disagreement on the project team, or it can be simply that collecting and organizing the information to create a good estimate will take time/effort that is not available at this stage. Every assumption is a risk
Like risks, assumptions only have value if you discuss them; the discussion is more valuable than the statement. The value comes from the process of the project team trying to establish boundaries/limits/constraints/probabilities.
The advantage of this approach (assumptions managed as risks) is that you avoid documenting assumptions that are trivial and nonmanagable. (I assume that the sun will not go nova during the course of this project; that's an assumption, but risk management would immediately classify it as not subject to further analysis.
Example 1: You indicated that the client is very concerned about security. Adversarial motivation and capabilities are frequently an assumption. You don't control the adversary. Unless your organization has a strong threat intelligence function, it is very difficult to measure this. But you can make assumptions about classes of adversaries - mostly around a 2x2 matrix comparing resources and targeting - you'll secure differently against a high resource low precision target like criminal conspiracies than you will against a high precision low resource actor like cyberactivists.
Example 2: Right now I'm supporting a project to develop training for a process that hasn't been developed. The training should exactly match the process behaviors and outcomes, but those haven't been documented yet. So we made and documented some assumptions about the process, and we've built our training on those assumptions. We need to monitor the assumption like a risk and act if it changes, but we have no ability to control or even influence the process definition.
Off the top of my head, the following are some potential assumptions (you may wish to cross post to the security stack exchange; in this case, I think cross posting will give you a very different insight).
Attackers will not have the resources of a nation state. (Defending against a nation state requires a very different level of resources). Attackers will be more similar to X. (This can be built out into a set of assumptions about attacker strength and motivation; depends on the sophistication of your client's threat intelligence).
The information stored on the network will be no more valuable than X (closely related to the prior) - I've had too much experience with networks built to secure information of type X and users insisted on story type Y. Once the amount of Type Y information on the network gets large enough, adversaries get interested. This is most common when users insist on storing PII on a network.
The owning agency has/does not have a policy about information aggregation. (in some cases fact X is not sensitive, but if you aggregate N instances of fact X, the information becomes sensitive). This is a classic case of something you don't control but have to manage.
WEP2 is resilient against the presumptive attackers for at least 5 years.
Our certificate provider continues to provide adequate certificate security (Certificate security involves people, processes and technology; as a certificate user/client, all you can do is to monitor that they pass their periodic audits).
There are no covert channels on my network, or the covert channels are low enough. (This used to be obscure, but SPECTRE & BEAST have proven otherwise).
Any federated authentication or access control will inform us of attacks in a timely manner.
Connected networks have correctly communicated their risk, residual risk, risk management and attack/incident information. (Another big case of information you don't control but which affects your success). Remember the Target network debacle? Your mission may require you to connect to a third party network; if they lie about their information security, or their transitive connectivity, or the degree to which they've been pwned, it can dramatically affect your security.
Security will be adequately funded.
- (this isn't a statement about your project - it is a statement about the security on which you rely. For example, SIEM/Incident Management is usually an outsourced function that you don't control; your success relies on them. For example, if you plan based on a 24x7 staffing with a 1 hour detection interval and a 80% confidence of Intrusion to Detection under 1 week, then you discover that their funding has been cut and they will be manned day shift by staff who have significantly less qualifications, then you need to re-evaluate your assumptions.
- this is also a template for any service that is outsourced, any service on which you rely.
Every Security Service Level Agreement is a set of assumptions about the relationship between your network and the other network. Every Memorandum of Understanding, every Interconnection Agreement, etc. Very few networks spend the time and effort justified here. How frequently do you exercise your SSLA/MOU/ICA? How often do your partners get audited and how much of that information do they share with you. (One of my favorite memories was managing a network that relied on a network provider; the network provider prohibited us from seeing any security testing data. We could not even see their authorization package or their security policy. Big danger signs. Turns out it was because they had not implemented their security - it was all vaporware.)
Security implementation will match security policy. (We all have experiences where the network team brags about the fancy firewalls they've bought, but when you see the firewall it is plugged into power, but not into the network. Or it is plugged in, but the admin password is shared among a team of 20+ and there is no configuration management, or ...)
Physical security is effective. All network security is based on the assumption that the adversary doesn't have unsupervised physical access to your network. Usually the network security team doesn't control physical access or personnel security. If the adversary can drop pwnie boxes or evil maid attacks, then they've bypassed your security.
You can build a number of assumptions from the old Orange Book Assumptions
- Assume that security is always invoked
- Assume that security is never bypassed
- Assume that security is comprehensive
