Preventing unauthorized access to some piece of information
or functionality. 

The key money-saving insight is to separate the volatile
part of some chunk of software from the stable part.
Encapsulation puts a firewall around the chunk, which
prevents other chunks from accessing the volatile parts;
other chunks can only access the stable parts. This prevents
the other chunks from breaking if (when!) the volatile parts
are changed. In context of OO software, a "chunk" is
normally a class or a tight group of classes. 

The "volatile parts" are the implementation details. If the
chunk is a single class, the volatile part is normally
encapsulated using the private and/or protected keywords. If
the chunk is a tight group of classes, encapsulation can be
used to deny access to entire classes in that group.
Inheritance can also be used as a form of encapsulation. 

The "stable parts" are the interfaces. A good interface
provides a simplified view in the vocabulary of a user, and
is designed from the outside-in (here a "user" means another
developer, not the end-user who buys the completed
application). If the chunk is a single class, the interface
is simply the class's public member functions and friend
functions. If the chunk is a tight group of classes, the
interface can include several of the classes in the chunk. 

Designing a clean interface and separating that interface
from its implementation merely allows users to use the
interface. But encapsulating (putting "in a capsule") the
implementation forces users to use the interface.