Systems should store a key value pair of Entity to Component in some sort of Map, Dictionary Object, or Associative Array (depending on language used). Furthermore, when you create your Entity Object, I wouldn't worry about storing it in a manager unless you need to be able to unregister it from any of the Systems. An Entity is a composite of components, but it shouldn't handle any of the component updates. That should be handled by the Systems. Instead treat your Entity as a key that is mapped to all components it contains in the systems, as well as a communication hub for those components to talk to each other.
The great part about Entity-Component-System models is that you can implement the ability to pass messages from one component to the rest of an entity's components quite easily. This allows a component to talk to another component without actually knowing who that component is or how to handle the component it's changing. Instead it passes a message and lets the component change itself (if it exists)
For instance, a Position System would not have much code in it, only keeping track of Entity Objects mapped to their Position Components. But when a position changes, they can send a message to the Entity involved, which in turn is handed off to all of that entity's components. A position changes for what ever reason? Position System sends Entity a message saying that the position changed, and somewhere, that entity's image rendering component gets that message and updates where it'll draw itself next.
Conversely, A Physics System needs to know what all of it's objects are doing; It must be able to see all world objects to test collisions. When a collision happens, it updates the Entity's direction component by sending some sort of "Direction Change Message" to the entity instead of referring to the Entity's component directly. This decouples the manager from needing to know how to change directions by using a message instead of relying on a specific component being there (which it may not be there at all, in which case the message would just fall on deaf ears instead of some error occurring because an expected object was absent).
You'll notice a huge advantage from this since you mentioned you have a Network Interface. A Network Component would listen to all messages coming in that everyone else should know about. It loves the gossip. Then when the Network System updates, the Network components send those messages to other Network Systems on other client machines, which then resend those messages to all the other components to update player positions, etc. Special logic might be needed so that only certain entities can send messages over the network but that's the beauty of the System, you can just have it control that logic by registering the right things to it.
Entity is a composition of Components that can receive messages. Entity can receive messages, delegating said messages to all of their components to update them. (Position changed Message, Speed Change Direction, etc) It's like a central mailbox that all components can hear from each other instead of talking directly to each other.
Component is a small part of an Entity that stores some state of the entity. These are able to parse certain messages and throw other messages out. For instance, a "Direction Component" would only care about "Direction Change Messages" but not "Position Change Messages". Components update their own state based on messages, and then update other components' states by sending messages from their System.
System manages all components of a certain type, and is responsible for updating said components each frame, as well as dispatching messages from the component's they manage to the Entities that the Components belong to
Systems could be able to update all of their components in parallel, and store all messages as they go. Then when execution of all Systems' update methods complete, you ask each system to dispatch their messages in a specific order. Controls first possibly, followed by Physics, followed by direction, position, rendering, etc. It matters which order they are dispatched in since a Physics Direction Change should Always out weigh a control based direction change.
Hope this helps. It's a hell of a Design Pattern, but it's ridiculously powerful if done right.