You have a python installation at work that already has certain packages installed. virtualenv creates an environment that has its own installation directories, that doesn’t share libraries with other virtualenv environments (and optionally doesn’t access the globally installed libraries either). Your question sounds like you may want to share libraries with your new virtualenv. Not having access to global site-packages is now the default behavior. But you can override defaults if this suits your use case. But a site-packages folder can not serve as a source for pip, but can be shared with another virtual environment - but (re-)creating the versioning issue virtualenv was made to solve.
For repeatabilty you can freeze the current list of packages using pip freeze. If you want to recreate this python installation at another system you need to tell pip where to find (any restricted set of) source packages if it should not use PyPI. If the company approved packages are available on PyPI - then just build up the new environment explicitly from a requirements.txt freezed from your default python installation. You can even build up a python env using editable installs - if you have access to source code of any company developed python packages.
pip has numerous options to install packages from different sources. Option 7 & 8 give you an idea how to install from source archives or from alternate package repositories or local filesystem.
pipenv invents something called a Pipfile. This file pins package dependencies and define sources (like PyPI) for dependencies. You have to find out how you refer to alternate sources. Order of [[source]]
entries may matter.
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"
[[source]]
url = "http://pypi.home.kennethreitz.org/simple"
verify_ssl = false
name = "home"
[dev-packages]
url = "http://mycompany.package.repo/simple/"
verify_ssl = false
name = "company-approved-packages"
[packages]
requests = "*"