This really is quite simple: you need to be running a domain. This is almost assuredly already the case for anyone who works for any company that has any servers. The first server in any Microsoft-centric network is almost always a DC, and the act of having a DC implies that you have a domain, and if you have a domain, then you have Group Policy available to you.

If you want your users to receive settings from Group Policy, the user accounts that they use to log into computers need to be domain accounts, and I think it goes without saying that the same is true for computers. If you would like to enforce settings on to computers or servers inside your environment, they must also be domain-joined. A domain is the hub for so many things inside any company network, including Group Policy processing and settings.

While Group Policy hasn't been around since the beginning of time, I also don't think that it is very important to spend too much time hashing out the details of what versions of Windows Server Domain Controllers have Group Policy, or what client-operating systems can take advantage of Group Policy settings. The reason this is not so important these days is because any operating system, both client and server, that Microsoft is still currently supporting does have Group Policy capabilities. In the very near future, we will start losing Microsoft support for Windows 7, and Group Policy has certainly been around for a lot longer than that.

So, the requirements for Group Policy = One Domain Controller.

However, if you want to establish a GPO and put some settings inside it and actually test it, then we'll need another device or user to which we can apply those settings and really test them out—so perhaps a DC plus a workstation.