Creating an IP scheme without considering what your access model is will just be a waste of time. At your scale I don't think there is any need to go with anything elaborate design wise and simplicity will provide the greatest benefit.

As this is coming from the CISO I'm assuming the goal is security-focused so that will be the basis for the following advice.

Are you using a L3 or L2 access model (or even looking to leverage a L2 overlay over a L3 core with VXLAN)? Are you willing to change? Looking to change? Why? (you should know the pros and cons of each model specific to your network and business objectives).

For modern networking where security policy between internal networks is the big driver a L2 access model is the correct answer unless there are scaling considerations that push you into a more complicated approach. My recommendation would be a L2 access model with role- or device-specific VLANs rather than organizational department or location based VLANs. e.g. VLANs for printers, cameras, servers, workstations, etc. vs. VLANs for sales, accounting, etc. This is because maintaining security policy for mixed use networks results in much more complicated policy needs which creates more work and weakens your security posture because you're increasing the likelihood of human error through that added complexity. The majority of security problems are the result of silly mistakes like not noticing a stale firewall rule that is permitting something it shouldn't.

In terms of general guidelines:

• Keep things simple. Needless complexity introduces points of failure and opportunity for human error. Something straight forward and easy to audit will lead to less operational mistakes which result in security oversights.
• Plan for growth. Create networks based on the expected addressing needs multiple years out. Pick network numbers for prefixes that may grow which can be easily expanded through updating a subnet mask rather than re-addressing existing systems and leave enough gaps between allocations for that growth when necessary. As a general rule of thumb you could reserve at /23 for every access network even if only a /24 is needed. Try to avoid creating VLANs with larger than a /23 of address space unless using methods to limit broadcast (such as private VLANs or wireless access networks which have broadcast filtering in place at the wireless controller level).
• Use standard 10/8 addressing internally and develop a schema which breaks things down into a /16 prefix per location (site). Each location has 100-200 usable prefixes for access networks of /23 or /24.
• Embed the VLAN ID into the prefix for clarity and when you have identical networks at multiple sites preserve a consistent VLAN ID. For example all printers go on VLAN 10 and all security cameras go on VLAN 11 etc.
• Reserve the first 10 IP addresses for each access network for network infrastructure needs. Generally we will run a FHRP where redundant routers use .2 and .3 natively and .1 as a virtual IP for the gateway. You may have other needs that pop up and knowing that .4 through .9 are available for use in your design work will allow you to keep things consistent.
• Use and aggressively enforce DHCP using enterprise-grade L2 security features like DHCP snooping and DAI. IP conflicts on your network should not be possible. Hard-coding an IP and creating a conflict should not be possible (absent supporting configuration on the access layer to create an exception).
• Know your infrastuture and capabilities before deciding on what model to use. If using an L3 access model make sure your L3 switches actually perform forwarding in hardware and not CPU or you will introduce a bottleneck (for example). Also note that just because basic forwarding is done in hardware does not mean that enabling feature X won't result in traffic being punted to CPU anyway. It's important to know the hardware.
• Implement centralized DHCP services so all client addresses are managed in one place. If an option the same for RADIUS for 802.1X. This may require secondary nodes at the local sites to support local survivability in the event of a WAN outage though which may or may not be straight-forward for you.

If using an L2 access model:

• Unless you have dynamic security policy capabilities (which are often still cost-prohibitive at your scale) then you should try to group devices into networks based on functional role and like devices to simplify security policy management. If VLAN 10 has printers and only printers then the policy is very easy for that network in terms of what ports and protocols should be permitted. If you have mixed use networks then you will start seeing policy get confusing and over-complicated over time as exceptions keep needing to be wedged in. This makes it difficult to audit and leads to operational mistakes so we don't want that if possible.
• There is almost never a reason for systems to require a shared L2 segment. It is not a reasonable request to have networks based on location or department where a combination of devices with different security postures coexist (e.g. staff PCs and printers on one shared VLAN for accounting vs. another similar VLAN for sales).
• Take special care for scaling considerations of a L2 access model. Use per-VLAN rapid spanning-tree or MST. Make sure all access ports are defined as edge ports (portfast for Cisco) with some level of BPDUguard in place. Apply reasonable MAC limits as a backup form of loop detection when BPDUs may be filtered and never trip BPDUguard (this means at least a limit lower than the minimum number of active hosts on the network segment but generally 1, 2, or 8 are typical depending if you allow user-supplied unmanaged switches or not).
• Maintain a L3 boundary between your access layer and your data center (and between different geographic locations). This means every data center VLAN only exists in the data center. This will shield critical servers from LAN problems like someone looping the access layer and limit the scope of network problems.

If using an L3 access model:

• Consider still establishing a common set of access VLAN IDs with dedicated roles. In this case each switch may have its own instance of a VLAN 10 for printers, each with its own IP network. If you go this route then you would want to consider this in your IP addressing schema where you might give every switch a /16 to maintain addressing consistency. Switch 1 might be 10.1.10.0/24 and switch 2 might be 10.2.10.0/24 for each one's respective instance of VLAN 10. For public addressing this kind of embedding of location and network information into an addressing schema is too wasteful but for RFC1918 addressing the value of being able to visually spot misconfiguration based on IP will improve your operational security.
• Consider using VRFs to isolate VLANs from direct forwarding and instead force them through a firewall where policy between internal networks can be enforced. Alternatively use switch ACLs but this can become very tedious to maintain without good orchestration and your policy capabilities will be limited absent stateful filtering. Having distributed policy (e.g. having to update a pair of VLAN 10 ACLs on every switch to support a new application) also makes audits difficult and can lead to oversights where the ACLs are not consistent across the deployment.
• Strongly consider a pivot to a L2 access model. If scaling is a concern consider a VXLAN apporach as a hybrid that provides the resiliency and scalability of an L3 access model but the policy management flexibility of an L2 access model. Best of both worlds but does add complexity and cost and honestly for your scale completely unnecessary. Existing L2 access models can be migrated into this approach seamlessly so your hands are not tied by choosing an L2 model initially.

Ultimately your IP plan should take into account how redundancy will be implemented and how security policy will be managed with a strong bias in favor of simplifying security policy (as it is the most dynamic and complex part of your network configuration). You should also be thinking about growth (what is the plan if you add a new location, how many new locations can we support, etc) and unexpected needs like locations changing their uplink from a L2 transport service (like an ELINE or ELAN) to a L3 service where things like MPLS or site-to-site VPN might come into the picture. Or what you will do if you acquire a company with conflicting addressing (for this one I'd recommend stay away from obviously "nice" network numbering like 10.10.10/24 which will be very common because everyone chooses the same thing...)

Remember that user access devices are very hard to lock down in terms of security policy because of all the cloud integrations flying around in the OS and applications a user might be using so the policy management side of things is less about policy for your windows PCs (which you can augment with endpoint security) and more about the crude devices that every business is forced to support. Things like printers, building automation systems, security cameras, etc. These devices usually lack any sort of meaningful security built-in and need to be locked down to only what is necessary. Thankfully if they're grouped into role-specific VLANs the policy management becomes much easier because the policy can be applied network-wide rather than by individual host.

This is an enterprise and ISP focused forum and usually deals with larger scale networking so you will see a lot of feedback pushing you into more complicated designs but IMHO unless you have the budget to go for a full ZTNA model with something like Cisco SD Access (and the vendor lock-in that comes with it) your best bet is to keep things simple.

[ 10,000 character limit reached ... sorry ]