Jeśli już tłumaczyć na polski, to zdecydowanie bardziej poprawne będzie "odwrócenie sterowania" niż "sterowanie odwrócone".

W uproszczeniu, z odwróceniem sterowania mamy do czynienia wszędzie tam, gdzie piszemy kod, nie udostępniając mu wiedzy o jego zależnościach.

Możemy napisać kod obsługujący sygnał dźwiękowy w samochodzie wywołując konkretną metodę some.namespace.Sounds.Honk() gdy zostanie naciśnięty przycisk. Możemy też napisać ten sam kod nie wiążąc go z konkretną klasą zawierającą Honk(), a ze stosownym interfejsem. Nie wiemy (nie mamy kontroli) nad tym, jaka implementacja zostanie wywołana, przekazujemy tą kontrolę implementującemu interfejs.

Jest to kluczowe przy pisaniu wszelkiego rodzaju frameworków - możemy oddać użytkownikowi frameworka kod, który zrobi za niego wszystko, o ile zaimplementuje on kilka kluczowych metod. Z perspektywy użytkownika frameworka, nie pisze on kodu, który woła konkretne metody (jak użytkownik biblioteki) - pisze on kod, który zostanie wywołany. I to jest właśnie odwrócenie kontroli.

Fakt, że zamiast wołać, jesteśmy wołani, powoduje, że na określenie IoC czasem używana jest fraza "the Hollywood principle". Jest to nawiązaniem do stwierdzenia "Don't call us, we'll call you.". Jednak, zupełnie inaczej niż w Hollywood, frameworkowi zdarza się zadzwonić.