I am working on providing wireless infrastructure suggestions to a client like what software, hardware and equipment will be required to a client in order for them to set up the wireless infrastructure. Its a production site that is quite big and the client want wireless connectivity in each of the areas and also doesn't want to allow access outside of its premises securing data. Security is a big concern for a client and the client cannot afford any downtime as its a critical business for him.

I am creating a document suggesting hardware, software, equipment etc to consider as well as creating a document that will cover Functional and Non Functional requirements. I am also to list the Assumptions but so far I feel like client told everything so what should be the Assumption I am just confused.

Can anybody guide/suggest me assumptions to consider for wireless network project?

  • This question looks too specific and it seems to be it's unlikely to benefit others.
    – Tiago Cardoso
    Commented Oct 4, 2020 at 21:19
  • Assumption 1: the project will be completed on time and within budget.
    – Solar Mike
    Commented Oct 5, 2020 at 10:28
  • I have to respectfully disagree with SolarMike on this one. Assumptions should not be things you control, and the discipline of project management is based on the assumption that the PM controls scope/schedule/cost.
    – MCW
    Commented Oct 5, 2020 at 11:27

2 Answers 2


"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).

  1. 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).

  2. 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.

  3. 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.

  4. WEP2 is resilient against the presumptive attackers for at least 5 years.

  5. 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).

  6. 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).

  7. Any federated authentication or access control will inform us of attacks in a timely manner.

  8. 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.

  9. 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.
  1. 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.)

  2. 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 ...)

  3. 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.

  4. 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
  • 1
    +1 You should send an invoice to the OP! :) Commented Oct 5, 2020 at 13:39

There are probably a number of assumptions that are fairly generic and apply to most projects, then there are other assumptions that relate specifically to your project. Generic assumptions will be things like the following, noting that this is not a comprehensive list:

  • Resources will be made available when required (people / finances / materials / equipment etc.)
  • The project structure will be such that there is a clear route for escalation of issues and risks;
  • Responsibility for procurement of equipment will be clearly defined and communicated to the project team;
  • The team will be co-located in (defined location) (or whatever the arrangement is);
  • The deliverables are clearly defined and any changes to them will be subject to formal change control;
  • Approval of any recommendations will be given within an agreed period (e.g. 3 days) otherwise the project timeline will slip;
  • Integration with existing technologies will be carried out by (a named team or person);
  • All technical standards will be defined and documented; the project must comply with these at all times;
  • Responsibility of technical design lies with (named person or team);
  • ...etc etc etc.

These assumptions (plus any specific ones for the technical aspects of your project) should be either approved by the project stakeholders, or if not, converted into risks that should be managed within the project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.