In a well design system, your actual password is never stored. Instead, a one-way function, called a hash, is used. Hash functions are mathematically designed so that there is no one-way relationship that allows you to do the function in reverse and get back the original input. You can get a basic understanding from this article.
In the backend, only the hash is stored. In the normal application logic, when the password is received from the user at login, it is hashed the same way as when the password was created. The stored hash value and the hash of the password typed at login can then be compared.
Using this design, we compare these password substitutes and never store the password. As a result, if someone found the hash in the backend, they would not have your password. They could not abuse the normal login flow with just the hash because they cannot reverse it. If the IT admin or a hacker only had access to the password hashes it would not be enough to do anything directly.
*Note: Password hashes cannot be reversed, but you could calculate values for given input passwords and see if the match. Salting
and other techniques can help to make this more difficult. Read the article I linked to above for an intro to the concept
In terms of password history, you don't need to store the passwords, but you can store all of the hashes as well. When you are asked to enter a new password, that password will be hashed and then that hash will be compared to all of the hashes in the history list. This means that no old passwords need to be stored directly, so no one can get to them.
It is also possible to use the hash history to test for passwords which are similar to those used in the past without knowing the plaintext:
For example, if you entered a password of "DogFood" you could also generate lots of variations using some algorithm so you would get something like {"dogfood", "DOGFOOD", "dOGfOOd", etc. }. The algorithm may try all sort of modiciations like character replacements, one off keys, check for incrementing numbers (e.g., if you do "password1" it will add "password2", "password3", etc). Then for each variation you also calculate the hash. If the hash of the original password or any of the possible variations match a hash already in your history then it is too close a match and will not be allowed.
The key point is that comparisons are never with the actual value, but with the hashes computed.
One last thing, it is possible for a system to "encrypt" instead of "hashing" passwords. In this case there is a higher likelihood of the actual password being exposed. However, hashing is used 99.9% of the time and password encryption is only used for specific needs or by a bad software design choice.